[linux-audio-dev] ALSA features.

[James Courtier-Dutton]

Dan Mills wrote:
> On Nice features, How about a helper function in the library to convert given 
> number of blocks of samples as say floats into the correct buffer format to 
> pass to the soundcard? It would cut lot a lot of (paraphrasing): 
> 
> if (snd_format = INTERLEAVED)
> .
> .
> .
> else if (snd_format == NON_INTERLEAVED)
> .
> .
> .
> else if (....)
> 
> which is both hard to debug without all the funky hardware out there, and 
> repeated in **LOTS** of ALSA applications.
> 
> Also there be lots of dragons with things like the ICE1712 taking 32 bit 
> samples and only using the UPPER 24 bits! 
> 
> IMHO Alsa lib at present does a poor job of hiding the scary hardware details 
> of this stuff from those applications which don't care. Sure it provides 
> plenty of functionality for Jack and friends which need to know about this 
> stuff, but many apps don't need to know about the memory layout of the buffer 
> and would be happy in blissful ignorance. 
> I suggested float as the input format but int would serve as well as long as 
> the maximum sample value supported by the card was easy to discover. 
> 
> Ohh yea, a similar function to unpack the card buffer back into individual 
> streams would also be nice. 
> 
> Just a thought.
> 
> Regards, Dan (I know, just use jack and be happy...). 
> 

Applications should not really be using ALSA device names like "hw:0,0" 
"hw:0,1" etc. They should be using "front", "rear" etc.
In addition to that there is a "plug" layer which is used if one opens 
the ALSA device with "plug:front", "plug:rear" etc.
This plug layer then lets the application use whichever sound format 
they wish to use and send it to ALSA. ALSA will then convert it to 
whichever format the hardware can handle and then send it to the card. 
So, using this method, no "helpers" are needed in the application.

There are also some extra api calls to modify how the "plug" layer acts.
By default, the plug layer will do resampling, sample format conversion 
etc. The ALSA resampler is not great, and the fix for that is in fact 
rather complicated so no-one has had the time to complete it. But, one 
extra api can specifically turn this "plug" feature off, so the 
application can then find out which sample rates the sound card can do 
in hardware, and then let the application handle the samplerate 
conversion. Much higher quality sample rate conversion is possible at 
the application layer.

So, I would say that ALSA does an extremely good job of hiding the 
hardware details from the user, but application have not all caught on 
to that fact yet.

James