Re: [linux-audio-dev] ALSA features.

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
Received on Sun Sep 4 16:15:05 2005