On Wed, Jun 15, 2011 at 05:24:20PM +0200, Christian Weisgerber wrote: > Alexandre Ratchov: > > > > I would, but there shouldn't be anything required to make it work. > > > The point of AC3/DTS pass-through mode is that it sends what looks > > > like 16-bit stereo audio at the S/PDIF level. It's only the receiver > > > that, on seeing a signature bit pattern, re-interprets the data and > > > decodes it according to AC3 or DTS. > > > > So, I don't even understand how AC3 would work at all. I mean, a lot > > of programs (ie all using sio_onmove(3)) expect that one second of > > s16le at 48kHz be exactly 192000 bytes of data. If AC3 is used, that > > wouldn't be true anymore (AC3 is 320kbit/s iirc) and audio would be > > broken. > > Padding, of course. A video player like MPlayer will format the > AC3 or DTS audio (both of which support numerous bit rates) in such > a way that the result is a 192000 byte/s stream. > > The data on a DTS CD is already preformatted to 176400 byte/s and > just needs to be passed through. I put the disk in, "cdio cdplay", > and the drive, cdio(1), and azalia(4) all think they are dealing > with 44.1 kHz 16-bit stereo audio when in fact it is 6-channel DTS. > > As designed, S/PDIF only transmits 20(!)-bit stereo audio at various > sample rates. However, ISO/IEC 61937 specifies how to carry various > non-PCM audio formats over S/PDIF by formatting them like a 16-bit > stereo stream. This is widely implemented for AC3 and DTS, rarely > for MPEG audio.
You're right. If data is properly padded, sndio can't make the difference between linear and compressed data (it counts bytes to extract the clock) > > And this can't be fixed without adding AC3 specific code. > > It is handled at the application level. Check out libmpcodecs/ad_hwac3.c > in the MPlayer source. There is nothing OpenBSD-specific about > this. It's the same for FreeBSD, Linux, and probably others. > indeed no code is needed as long as padding is handled by apps. -- Alexandre
