M-Audio revolution 7.1 only supports 32bit output with oss4?

[barrystat]

I am setting up oss4 to play 24bit flac files with my M-Audio revolution 7.1. According to the specs, this card supports 24bit playback. I use Debian Wheezy with oss4 (4.2-build2006-2) from the repo. I disabled vmix0-enable and set vmix0-src to OFF and the 24bit flacs play with the correct sample rate and without any distortions.
Strange thing I found is that ossinfo gives me 32bit as only supported output (no 16 and 24 bit):

Input formats (0x00001000):
AFMT_S32_LE - 32 bit signed little endian

Does anybody know what is happening here and if I have a correct playback of these files?

[igorzwx]

I am setting up oss4 to play 24bit flac files with my M-Audio revolution 7.1. According to the specs, this card supports 24bit playback. I use Debian Wheezy with oss4 (4.2-build2006-2) from the repo. I disabled vmix0-enable and set vmix0-src to OFF and the 24bit flacs play with the correct sample rate and without any distortions.
Strange thing I found is that ossinfo gives me 32bit as only supported output (no 16 and 24 bit):

Input formats (0x00001000):
AFMT_S32_LE - 32 bit signed little endian

Does anybody know what is happening here and if I have a correct playback of these files?

1. "Correct audio playback" has never been promised by "open source" developers. What is promised is PulseAudio compatibility. The reason is obvious. Ubuntu/Debian users are not supposed to be able to hear the difference.

2. To disable format conversion, you may need to hack the code of OSS4.

3. Presumably, format conversion might be disabled with "ossplay -R". "How to ensure correct playback" is not covered by OSS4 documentation largely because, perhaps, the users are supposed to be "semi-deaf". Although OSS4 is said to be "well-documented", the users are invited to study the source code to find out how it works.

4. You may want to post the output of "ossinfo -v9".
It should be marked as "code", for example:

Code: Select all

$ ossinfo -v9

Syntax:

Code: Select all

[code]$ ossinfo -v9[/code]

Code: Select all

$ man ossplay
       -R     Disable  redirection  to  virtual  mixer  engines   and   sample
              rate/format  conversions.  Should  not be used unless absolutely
              necessary.

If you do not believe, you may study the "source code". In essence, "open-source" is a kind of religion rather than an "exact science". You have to believe. Otherwise, it does not make much sense. You have to learn "how to fool yourself and others". The manual is here: Cargo Cult Science (html) by Richard P. Feynman Of course, the infidels, heretics, and dissidents may want to verify something by "clear-cut empirical tests". Such "strange ideas" are not welcome for understandable reasons.

EXAMPLES:

Code: Select all

$ ossplay -R -vvvv mumu.wav

Code: Select all

$ ./strac* -e trace=ioctl,open ossplay *.wav -R
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfb5bc3c)        = 0
open("Tabla.wav", O_RDONLY) = 4
open("/dev/dsp", O_WRONLY|O_EXCL)       = 3
ioctl(3, 0x4004501e, 0xbfb5b17c)        = 0
ioctl(3, 0x40405902, 0xbfb5bcb4)        = 0
ioctl(3, SNDCTL_DSP_GETODELAY or SNDCTL_DSP_PROFILE, NORMAL => NORMAL) = 0
ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, S16_LE => S16_LE) = 0
ioctl(3, SNDCTL_DSP_CHANNELS or SOUND_PCM_READ_CHANNELS, 2 => 2) = 0
ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 44100 => 44100) = 0
^C


Notice that "only a special strace binary will decode the ioctls".

[cesium]

Since 24 bit is somewhat of an unnatural bit rate (there aren't many 24-bit processors out there), the 24bit format is in practice usually 3 bits followed by a null byte (i.e. 4 bytes are actually sent to the cards - there's no resampling involved since the only addition is a single null byte every sample). So I suspect having your card support 32bits and playing '24' isn't so surprising, but actually rather natural. (OSS defines the 'real' 24bit format as AFMT_S24_PACKED or something like that and there are a few (IIRC, USB) cards which do that, but I can't think of advantages to this as a playing format, except perhaps for a USB card on USB1.1?).

[Edit: see also here and here - as I wrote the typical 24bit format is actually using 4 bytes. I didn't know S24 could use a part of the 4th byte if the sample is negative...]

[igorzwx]

So I suspect having your card support 32bits and playing '24' isn't so surprising, but actually rather natural.

If the format conversion is not disabled, it would be automatically converted to a proper format. Right? Such a "format conversion" is a lossy conversion, by definition. This is the problem.

Could this be clarified with your "special strace"?

1. OSS4 does not support 24bit with Intel HDA codecs.
2. 24bit flacs can be downloaded from 2L website http://www.2l.no/hires/index.html
3. They can be converted to waves with "flac -d"
4. Format can be verified with "mediainfo *.wav"
5. Format conversion might be disabled with "ossplay -R"

If your "hypothesis" is not a "theological hypothesis", it should be possible to design a "clear-cut empirical test" to verify it. Right?

[cesium]

Fair enough. Having tried this, I noticed that every program I fed the flac (or decoded wav) to performed some form of format conversion (e.g. ossplay has 24->32 bit conversion even with -R, which I should have remembered since I put it in... [which was because almost no cards support S24_PACKED]). But this isn't necessarily lossy (though it may be buggy, or the program may choose a 16bit format where the conversion would be slightly lossy - though this is not the case with barrystat's card since it doesn't support 16bits - of course that using strace to verify this can't hurt), no more than converting a zip to rar 'has to be' lossy. The sample data isn't changed at all - only the sample format is changed and if the change is 24->32 bit, the change is trivial and doesn't have to lose data.

As for the original question of how to verify this, I guess we can assume the card plays back correctly what is sent to it (or at least, it's a separate problem then alleged lossy format conversions and would require different tests). To test the conversion, barrystat could follow the wiki's Tips and Tricks page and record the output before it reaches the card and compare it to 'flac -d'.

Some pitfalls:
* There's a need to convert the flac output (or the recorded output) so that both use the same format before the compare. However, the conversion program might be bugged in theory. So using more than one (and/or using the same program to convert both sides to a common format - which is useful anyhow [see below]) to test is IMHO required.
* a false positive might happen if not taking into account the recorded file's headers might be different then the one given by 'flac -d' (after all, there's no guarantee or necessity they be completely equal). Converting _both_ sides by the same program has the advantage the converting program probably writes the output headers the same way.
* Probably more that I forgot right now.

[igorzwx]

There's a need to convert the flac output (or the recorded output) so that both use the same format before the compare. However, the conversion program might be bugged in theory.

Are you going to say that FLAC is a lossy format, because it is "open source"? In any case, 24bit waves can also be downloaded from 2L website http://www.2l.no/hires/index.html

You do not like FLAC, because it is not compatible with your ossplay. Right? Have you already tried to compress your test wave for surround playback into flac, then decompress it to wave, and play it with ossplay? The result might be very strange. The same problem may occur when you decompress 2L surround flacs into waves and play them with ossplay.

Code: Select all

$ man ossplay
       -R     Disable  redirection  to  virtual  mixer  engines   and   sample
              rate/format  conversions.  Should  not be used unless absolutely
              necessary.

ossplay has 24->32 bit conversion even with -R, which I should have remembered since I put it in...

Thanks! This seems to mean that OSS4 documentation is obscure and misleading.
I tend to use Petrov's plugin with DeadBeef player. Although this plugin is "closed source", it seems to be much more reliable than "open-source" alternatives.

Audacious also makes lossy conversions. Moreover, Audacious is so designed that it might be impossible to disable lossy conversions. It might be much easier to create a new player than to remove all "open-source crap" from Audacious.

The Russian DeadBeef Player is "open source", and, therefore, it is likely to have a kind of PulseAudio inside, or other "open-source crap" of the sort. It also makes lossy conversions. It seems that Petrov's plugin can somehow disable lossy conversions in DeadBeef, but it might be difficult to verify.

The OSS4 driver for LynxTwo is "closed source", and, therefore, it should support 24bit. Right?
http://manuals.opensound.com/usersguide/lynxtwo.html
http://ixbtlabs.com/articles2/lynxtwo/

In any case, to play HiRes FLACs without lossy conversions, you may need a special "lossless player", which may not exist. The "deaf composers" may not need such a player, because they may not hear the difference. To produce "digital crap" with LynxTWO and OSS4, they may need Ardour and jackd1 http://ardour.org/node/4370

LynxTWO is an ancient soundcard, a kind of Stone Age technology, but it is, at least, a dedicated device for sound recording. In our day, it might be utilized for playing HiRes flacs with a "lossless player" (which may not exist).

Is it really so difficult to create a very simple player, which can play flacs and waves without lossy conversions?