From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1250217915.26729.63.camel@goose.sun.com> References: <38fa4d234fa7ff8613123fe9a6921943@quanstro.net> <13426df10908112014y49c5a89dpd616ce4529c1efe1@mail.gmail.com> <7DD19FED-D73E-44A3-8710-4F70D9293F34@sun.com> <1250217915.26729.63.camel@goose.sun.com> Date: Fri, 14 Aug 2009 15:56:22 +0200 Message-ID: From: hiro <23hiro@googlemail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [9fans] audio standards -- too many to choose from Topicbox-Message-UUID: 49840acc-ead5-11e9-9d60-3106f5b1d025 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 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. > > >