Re: [ecasound] Problems with 24/96 over stdin

From: Kai Vehmanen <kvehmanen@email-addr-hidden>
Date: Wed Apr 22 2009 - 23:47:14 EEST

Hi,

On Wed, 22 Apr 2009, kls.schlz@email-addr-hidden wrote:

> As I mentioned earlier. It is all about Alsa compliance. Either ecasound
> is compliant or it is not compliant. Currently it's not.

well, I don't really agree with that. On the contrary, ALSA design is such
that applications (like ecasound) only need to support _one_ audio format
offered by ALSA, and alsa-lib takes care of any needed conversions (unless
it is explicitly forbidden from doing so). Ecasound would be a perfectly
usable and compliant ALSA application even if it'd only support S32_LE.

The big selection of audio formats in ALSA is there because the audio
hardware drivers need them. There are tons of sample formats defined in
ALSA that are not supported by most apps (aplay/record is an exception as
it is used by driver developers to test driver code) - e.g. how many apps
support S20_3BE, U18_3LE, U24_3LE...? For certain, supporting these is not
required for an application to be ALSA compliant.

For instance, most 24bit hardware interfaces use S32_LE/BE (all M-Audio
cards, RME Hammerfalls, USB audio profile, Intel HDA based soundchips,
Echoaudio Darla/Gina/etc, SB Audigy, ..), and most file formats use
S24_3LE. I.e. ecasound supports two of the most common 24bit sample
formats. While S24_LE is used by some HW interfaces (mostly embedded
chips, e.g. some Wolfson WMxxxx audio chips), it is much less commonly
used than the two other 24bit sample formats. And definitely in
applications, S32_LE is more commonly used (and F32_LE is even more
common).

If you look apps that support piping 24bit samples, brutefir uses S32_LE,
while flac, sndfile-convert, sox and ecasound support S32_LE and S24_3LE.
MPD won't be able to talk with any of these if it only supports MSB-padded
24bit samples.

Now I still think having ecasound support MSB-padded 24bit samples would
be a nice addition, but I don't think this has anything to do with ALSA
compliancy.

> The more philosophical question if one needs that ALSA S24_LE format,
> should IMO be discussed with the Alsa folks.

I don't think that's necessary. ALSA has S24_LE, because it needs it for
interfacing with audio hardware. But S24_LE is not the official ALSA 24bit
format (as there is no such thing). If MPD implements only one 24bit
sample encoding, S32_LE would be the safest choice (works with
aplay/record, ecasound, brutefir, flac, sox, sndfile-convert, ...).
S24_3LE would be still good, but with only S24_LE you really limit the set
of apps you can talk to.

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Thu Apr 23 00:15:01 2009

This archive was generated by hypermail 2.1.8 : Thu Apr 23 2009 - 00:15:01 EEST