Device claim protocol

Device claim protocol

Post by Christopher Bazle » Fri, 25 Jul 2003 21:35:39



Dear all,

The device claim message protocol described in the PRM says that you
can (and presumably should) send a Message_DeviceClaim for major device
no. 6 to claim exclusive use of the entire sound system. But when this
was written things were much simpler since there was only the original
Archimedes 8 bit sound system.

Since then things have become much more complicated: There may also be a
16 bit linear handler, which can be used in parallel with the DMA
handler's emulation of 8 bit sound - but only by one program, unless
SharedSound is used.

Generally SharedSound will claim exclusive use of the 16 bit sound
system, but the latest versions will also drive the 8 bit sound system,
as an alternative for older machines. Since SharedSound doesn't have a
Wimp task, it can't use the device claim protocol to enforce either of
these claims.

The simple answer appears to be to assume that the device claim
protocol only applies to the 8 bit sound system (real or emulated),
except when you consider that installing a SharedSound handler on older
computers may also reconfigure the 8 bit sound system.

I suppose the code to handle this possibility would look something like:

IF SharedSound module loaded THEN
  IF 8 bit sound only THEN
    send Message_DeviceClaim for device no. 6
  ENDIF
  install SharedSound handler
ELSE
  IF 16 bit sound supported THEN
    install 16 bit handler
  ELSE
    send Message_DeviceClaim for device no. 6
    use 8 bit sound system
  ENDIF
ENDIF

Bizarrely, PRM vol 5a's recommends that you re-register the previous
linear handler when relinquishing control of the 16 bit sound system.
Given that this could wreck the computer (for example if the previous
claimant has gone AWOL) surely it would have made more sense to extent
to device claim protocol to cover 16 bit sound? :-/

Any thoughts?

--
Chris Bazley
===================================================================
My corner of the web: http://www.bigfoot.com/~chrisbazley/
Star Fighter 3000 web home: http://www.starfighter.acornarcade.com/

 
 
 

Device claim protocol

Post by John Duffel » Sun, 27 Jul 2003 20:21:55




[snip]

Quote:

> Generally SharedSound will claim exclusive use of the 16 bit sound
> system, but the latest versions will also drive the 8 bit sound system,
> as an alternative for older machines. Since SharedSound doesn't have a
> Wimp task, it can't use the device claim protocol to enforce either of
> these claims.

SharedSound re-registers itself frequently, it should be the LinearHandler
all the time really.  I expect the non SharedSound claim method is deprecated
anyway.

[snip]

Quote:

> I suppose the code to handle this possibility would look something like:

[snip]

Nowadays you would be better off ignoring everything except SharedSound, and
just RMEnsure it.  I can't see anyone having a problem with that, since it's
provided in ROM on recent RO and available in !System.  It might well be
worth looking at SharedSoundBuffer from http://www-users.york.ac.uk/~jwd104/
which simplifies things for sound producing programs, especially if they
aren't modules.

Quote:> Bizarrely, PRM vol 5a's recommends that you re-register the previous
> linear handler when relinquishing control of the 16 bit sound system.
> Given that this could wreck the computer (for example if the previous
> claimant has gone AWOL)

If you have claimed the LinearHandler and you are rmkilled, you should check,
and if you no longer own it, refuse to die, because you may be reinstated
later.

Quote:> surely it would have made more sense to extent
> to device claim protocol to cover 16 bit sound? :-/

> Any thoughts?

Basically SharedSound is designed to get around all of these issues, all you
do is register and it does all the hard stuff.  Unless you have a need to run
on machines which don't/can't have SS then just demand it.

HTH,
--
John
http://duffell.cjb.net/  http://www-users.york.ac.uk/~jwd104/

 
 
 

Device claim protocol

Post by Christopher Bazle » Mon, 28 Jul 2003 19:09:16




[snip]

Quote:> > Bizarrely, PRM vol 5a's recommends that you re-register the previous
> > linear handler when relinquishing control of the 16 bit sound
> > system. Given that this could wreck the computer (for example if the
> > previous claimant has gone AWOL)

> If you have claimed the LinearHandler and you are rmkilled, you should
> check, and if you no longer own it, refuse to die, because you may be
> reinstated later.

Hmm... what I'm doing on exit at the moment is:

IF our linear handler still attached THEN
  IF our sample rate not changed THEN
    restore old sample rate
  ENDIF
  remove our linear handler (handler = 0)
ELSE
  somebody else using 16-bit sound - don't touch anything
ENDIF

I just couldn't bring myself to attempt to restore the previous handler -
it's crazy to re-instate a long stale code pointer that points god knows
where. If you were to do it like the PRMs, what would the poor old user
make of inexplicably having to load and quit their applications in a
certain order?!

Things are much more complicated with attempting to restore the 8 bit
sound system:

IF same channel handler installed THEN
  restore overall volume
ENDIF
FOR channels...
  IF our voice still attached THEN
    reattach old voice
    IF same channel handler installed THEN
      restore old stereo position
    ENDIF
  ENDIF
NEXT channel
remove our voice
IF same channel handler installed THEN
  IF no. of channels same as we configured THEN
    restore old no. of channels
  ENDIF
  IF sample period is same that we configured THEN
    restore old sample period
  ENDIF
ENDIF

The 'same channel handler' business is necessary to cope with the many
Tracker players that temporarily replace the channel handler (to get
lower level access to SoundDMA). All things considered, it is perhaps
unsurprising that so many programs leave the sound system in an
indeterminate state! :)

Quote:> > surely it would have made more sense to extent
> > to device claim protocol to cover 16 bit sound? :-/

> > Any thoughts?

> Basically SharedSound is designed to get around all of these issues, all you
> do is register and it does all the hard stuff.  Unless you have a need to run
> on machines which don't/can't have SS then just demand it.

My program does need to run on RISC OS 3.1 machines - which the latest
SS does support - but see below:

The trouble with SharedSound, and indeed any linear sound handler
implementing volume scaling and/or mixing, is that it is incredibly CPU
intensive compared to the equivalent 8-bit log voice generator. You
can't do mixing by simply interleaving samples, and volume scaling
requires many MULs. On a pre-Risc PC machine (which is least likely to
cope with this) you also have the cost of conversion by SharedSound to
interleaved 8-bit log output.

The 8-bit sound system is much 'nicer' than the raw 16-bit system for
applications like music players, because you get to use the scheduler and
channel handler, and there is a modular system of voices. By contrast, the
16-bit handler (SharedSound or not) just dumps you in at the deep end. For
this reason I don't think the 8-bit system will ever be abandoned
completely.

Also, the Scheduler is potentially very useful on it's own, since it can
be used to schedule any suitable SWI (I have successfully used it to
schedule notes on a 16-bit linear handler). But since it has only one
beat counter, bar length and tempo, you still need to indulge the
device claim protocol even if you're not using the rest of the
Archimedes sound system.

One final observation: SharedSound's new support for driving the 8-bit
sound system seems to be quite badly broken. I find that issueing
*RMKill SharedSound on an A5000 (having once installed a SS handler)
will consistently crash the machine.

All the best,
--
Chris Bazley
===================================================================
My corner of the web: http://www.bigfoot.com/~chrisbazley/
Star Fighter 3000 web home: http://www.starfighter.acornarcade.com/

 
 
 

Device claim protocol

Post by John Duffel » Mon, 28 Jul 2003 22:11:28








> [snip]

> > > Bizarrely, PRM vol 5a's recommends that you re-register the previous
> > > linear handler when relinquishing control of the 16 bit sound
> > > system. Given that this could wreck the computer (for example if the
> > > previous claimant has gone AWOL)

> > If you have claimed the LinearHandler and you are rmkilled, you should
> > check, and if you no longer own it, refuse to die, because you may be
> > reinstated later.

> Hmm... what I'm doing on exit at the moment is:

> IF our linear handler still attached THEN
>   IF our sample rate not changed THEN
>     restore old sample rate
>   ENDIF
>   remove our linear handler (handler = 0)
> ELSE
>   somebody else using 16-bit sound - don't touch anything

...and refuse to die, with an appropriate error, assuming you're not already.

Quote:> ENDIF

> I just couldn't bring myself to attempt to restore the previous handler -
> it's crazy to re-instate a long stale code pointer that points god knows
> where.

The module which it points to will still be there since it has refused to die
when it realised it wasn't the current linearhandler.

Quote:> If you were to do it like the PRMs, what would the poor old user
> make of inexplicably having to load and quit their applications in a
> certain order?!

If you do it your way, the module which had it before will never be able to
quit, since it will forever be expecting to be reinstalled.  That's why the
PRM specifies its way.  It probably isn't the best way, but it's worse if
some people follow the standard and others support parts of it.

I'm not sure if you mean it or it's just wording, but you seem to be saying
"application", but applications should never be claiming the sound handler
(unless you're doing something odd like claiming some rma and putting code
in, but that's not recommended by me at least).  You can quit applications
when you like, it's just the modules you can't.  I usually just leave the
module running for later, or for other people to use.

Quote:> Things are much more complicated with attempting to restore the 8 bit
> sound system:

[snip]

I can't speak about the 8 bit system since I've never had any contact with
it, sorry :)

[snip]

Quote:

> The 8-bit sound system is much 'nicer' than the raw 16-bit system for
> applications like music players, because you get to use the scheduler and
> channel handler, and there is a modular system of voices. By contrast, the
> 16-bit handler (SharedSound or not) just dumps you in at the deep end. For
> this reason I don't think the 8-bit system will ever be abandoned
> completely.

Probably right, I never used it :)

Quote:> Also, the Scheduler is potentially very useful on it's own, since it can
> be used to schedule any suitable SWI (I have successfully used it to
> schedule notes on a 16-bit linear handler). But since it has only one
> beat counter, bar length and tempo, you still need to indulge the
> device claim protocol even if you're not using the rest of the
> Archimedes sound system.

Just write a multi-session SWI scheduling module.  There's no need for
something like that, which doesn't need exclusive access to resources, to
only be usable by one client at a time.  I realise that that is peripheral to
the main question anyway.

Quote:> One final observation: SharedSound's new support for driving the 8-bit
> sound system seems to be quite badly broken. I find that issueing
> *RMKill SharedSound on an A5000 (having once installed a SS handler)
> will consistently crash the machine.

Ah well :)  I just don't support RO3.1, it makes my life easy :)

HTH,
--
John
http://duffell.cjb.net/  http://www-users.york.ac.uk/~jwd104/

 
 
 

1. Broadcasts, acknowledgements, device claim protocol etc.

Another little quessy.

I'm using the device claim protocol to claim a serial device, and
noticed something strange.  Using WimpMon to track the messages
(Tom; that's an extremely useful little app!) I see the following
sequence (no-one else claiming the device):

   1) App broadcasts device claim; recorded (18)
   2) App receives broadcast back to itself (18)
   3) App receives copy as nack (19)

Is this always the case with when broadcasting a message recorded?
That both the broadcast returns and the nack occurs?  Or is the
device claim message not intended to be sent recorded (when broadcast)?

Currently I'm just throwing away broadcasts that are returned.

--
This .sig under destruction

2. MR26A All House Code Receiver

3. Device Claim and the serial port

4. bitmap on mainWindow

5. Growing module area - strange claims

6. Hardware Failure rate vs Time

7. Cannot claim printer.

8. Help needed with scenery problem ( FS6 )

9. Cannot claim stack for filing system.

10. Intel and Java speed claims?

11. Claiming the SWI processor vector

12. Claiming EventV

13. Claiming the serial port