Audio: future improvements?

The “gapless playback” Jim refers to is surely a property of the player application and not of the RISC OS sound system?

The “gapless playback” Jim refers to is surely a property of the player application and not of the RISC OS sound system?

I guess the answer is ‘yes’ to that. However I was raising it as another of the things other platforms are now taking for granted.

Jim

I used to have a Sharp “portable” record player that could play both sides of a disc. Hit “Both sides” and “×3” and you wouldn’t have to get out of the chair for two hours!

However I was raising it as another of the things other platforms are now taking for granted.

You start down that track, we might be here a while…

You start down that track, we might be here a while…

and the title of this forum is…?

So, away you go.

You start down that track, we might be here a while…

Erm… yes. :-) However I think this may have expanded a bit beyond my original reasons for starting the topic. I’ll try again with a narrower focus to make my main concern a bit more concrete.

24bit.

At present ARMiniX (and similar) owners have a machine whose hardware can happily play 24bit material at rates up to 96k. And 96k/24bit is becoming more and more common. I already have a fair collection of such files (generally flac).

I can at present play versions processed down (e.g. by sox) to 96k/16bit and they work nicely.

So we have 24bit source materials and 24bit hardware. But at present no path from file to hardware for 24bit audio.

To deal with this I presume that we not only need players and drivers that can read and pass 24bit. But to have modules like SharedSound or SoundDMA and the HAL be able to handle it.

That clearly needs work to actually impliment. But it seems to me that step 1 would be to define the agreed extended API for this, so that anyone working on a player, driver, or changing the modules (or creating 24bit alternatives) would all be working from the same specs. This would ensure compatability.

Hence my central point has been that we need to look at defining an extended API for this even if no-one is immediately making any changes to any specific driver, module, etc. Once the API is defined and makes sense to those involved, people could impliment extended drivers, etc, as they see fit. e.g. Versions of apps like DigitalCD/PlaySound and drivers like PlayIt could have 24bit handling added that uses the API to allow this to function alongside being able to go on playing 16bit.

FWIW I’m not sure, but I suspect might be easier to have a new API flag/mode that works with 32bit words as one word per sample, as distinct from the current 16bit ‘half word’. Then 16, 24, – and even 32bit (even float) in future – could be covered. Yes some people are already using 32bit audio samples, sometimes float. But that’s pretty rare as I doubt it will be popular soon. So the main focus should be an API for 24bit which then becomes implimentable. But perhaps pencils in the space for 32bit as well.

Jim

BTW in case it is of interest I’d like to say that I’ve finally got around to putting up the webpage on the amp/filter/volume control for the ARMiniX.

http://www.audiomisc.co.uk/RO/SoundsGood/PassTheMusic.html

Jim

USB audio presents new problems for SharedSound. I presume we want to keep SharedSound as the central controller and interface for the sound system.

Previous audio interfaces are permanently there in the hardware. USB audio interfaces come and go as they are plugged and unplugged. It seems to me that SharedSound has to be notified of their arrival and departure, also must have ways to interrogate devices for their capabilities, and ways to control their settings.

USB audio presents new problems for SharedSound. I presume we want to keep SharedSound as the central controller and interface for the sound system.

Yes and no… i.e. I guess it depends on some other factors as well.

We could decide that adding/removing external USB DACs, etc, is a matter of making SoundControl more flexible. Since SoundControl is meant to be the controller for hardware you can argue this either way.

As yet I’m far from clear of the details of both modules. e.g. How does SharedSound actually do interpolations, and when will that do them rather than a driver like PlayIt?

Having good external DACs also leads to the questions I’ve been raising about how to handle sources with various rates when the DAC can accept them all – so may need no interpolations at all if we have ‘pass the parcel’ mode available.

Whereas we may need better interpolations for cases where the above isn’t true.

Which means more user flexibility and ability to modify things like choice of output, the way it is handled, etc.

Alternatively, for now we could bypass some problems in the short term if we simply made the USB a new route for something like PlayIt to drive ‘directly’ and bypass SharedSound and SoundControl. That would probably mean getting success much more quickly and easily. But might mean problems later on with a split in the ways in use. Would be useful as a first method, though, to cut out as many complications as possible, and ideal for ‘purists’ like myself. So in that sense a ‘quick and hacked’ route might actually give the best outcome. As it is, people can choose the driver route and – e.g. bypass SharedSound already – if they wish. Indeed, I’ve been wondering if that might be useful in some circumstances.

Jim

Having though about this a bit more two other alternatives occur to me as possibly being useful in the short term, and then maybe afterwards.

A) Perhaps initially focus on having a dedicated ‘USBplayer’ which assumes a USB audio device is attached, and plays a file whose name it is given. In effect a parallel to the software for reading and manipulating files on cameras that aren’t mass storage devices. The audio file is ‘copied’ to the USB device. In effect this is what happens anyway as the device asks for blocks of data as suit it. So it just seems to take a while to read the whole file. This approach may be the quickest way to get something that works as it sinply makes its own direct path from source to device.

B) Maybe a more direct approach than trying to modify SharedSound is to use a specific USB version of SoundDMA which is softloaded over the default module when a device is attached and recognised. This then feeds the USB DAC rather than the default HAL.

Jim

(I think this is the appropriate thread.)

Jim, per email discussion would it be helpful if someone here could offer to make bsd/RiscOS/Sources/Audio/SharedSnd/Docs/Spec,bc5 available in another file format? (I only have an old copy of Impression Style myself and ISTR that not working anyway with my RiscPC in its current set-up… and boxed up too, just to be awkward.)

Edit: I think this is now in hand, thanks to Robin and Ben.