I think I can consider myself lucky, that my equipment doesn't know how to do AC-3 or DTS :) Although my soundcard does have some other interfaces i.e. for a S/PDIF clock source.
On Fri, Aug 14, 2009 at 4:45 AM, Roman V. Shaposhnik<r...@sun.com> wrote: > On Wed, 2009-08-12 at 17:36 +0200, hiro wrote: >> > This sounds like exactly the kind of thing one wants >> > from an audio driver for playback. For recording things >> > get slightly more complicated. >> >> What exactly do you mean? > > Now that I understand what Tim is trying to do my original > concern makes no sense. Sorry for this little bit of noise. > >> >> > Even for playback if you want to do passthrough (via >> > SPDIF or some such) things get slightly more complicated. >> > Of course, one can disregard passthrough as not >> > being an audio at all, but rather a datalink issue. >> >> What's so special about things like SPDIF? > > Two things: the data traveling over the link can be any data, not > just some form of PCM (it can be AC-3, it can be DTS, it can even > be MP3). In that respect the audio card acts as a pass-through > device. It is not really supposed to do anything with the > data. And that brings us to the second point -- the pass-through > APIs can be as ugly as hell, depending on the type of the device > (follow the link to the MPlayer docs I provided in this thread). > >> Why would it be not suitible for the kernel audio driver? > > Because it has very little to do with the PCM audio, and that's > what the driver discussed in this thread was supposed to be all about. > Now, I'm not saying that there's shouldn't be a special driver just for > pass-through type of functionality, all I'm saying is that > lumping this functionality together with the PCM one would > confuse things. > >> For me it's clearly an audio and >> not a datalink issue, but perhaps I have only limited use cases. > > Perhaps, everywhere in this thread I should've prefixed the word > audio with "some form of PCM". > > Thanks, > Roman. > > >
