<html><head><style type="text/css"></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div>Hi, 1. I was wondering if MP3/DTS/AC3 passthrough is at the discussion point only or is someone actively looking at developing it? 2. I think that encoding needs to be considered as part of the design ie. the possibility of AC3 or MP3 encoding before output to SPDIF. Perhaps you're already past this point, but there is an Alsa utility iecset which returns (and can set) whether raw data or PCM is being passed to SPDIF. So presumably the Pulseaudio passthrough for Alsa just needs to call the same function that utility does. Can someone point me to any design and API docs for Pulseaudio as I'm interested in learning where and how it connects to Alsa? Cheers, Mike </div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"> <div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><hr size="1">From: pl bossart <bossart.nospam@gmail.com> To: General PulseAudio Discussion <pulseaudio-discuss@mail.0pointer.de> Sent: Fri, 9 July, 2010 16:51:21 Subject: Re: [pulseaudio-discuss] {PATCH][RFC] AC3 passthrough support > I agree that it's not really a good solution to require the user to > change the card profile manually to enable passthrough via spdif. But as > I said, a separate module could take care switching between the profiles > as needed. I don't understand your proposal. What do you mean by separate 'module' and how would this work with the current mixer profiles? > Having thought this for a while, the only thing that really irritates me > in your design is that the semantics of the PA_SINK_PASSTHROUGH become > messy: the flag says that "in addition to normal PCM streams, this sink > supports also passthrough streams, except at times when there already > exist PCM streams, and btw, while a passthrough stream is playing, PCM > streams cease to be supported". I guess that's not a very practical > problem, though. It's not really my design, it's just how SPDIF/HDMI work... > Ah, but now a better argument popped into my mind. If a sink can enter > the passthrough mode on the fly, then that has a consequence that > affects any application that is interested in sink volumes: whether a > sink has adjustable volume can change any time. That's not very nice. Duh? If we fixed the volume stuff so that that the volume control app disables its sliders when passthrough AC3 is enabled, what would be the issue. This is how VLC works, when you stream AC3 data the volume control is no longer enabled. > Even if we have only two formats, iec958 and mp3, I don't see why the > sink flags would the proper place to specify the format. I believe most > of the passthrough related code is only interested in the fact that the > stream data shall not be touched. If there are multiple flags for all > the different passthrough formats, then all that code will have to check > for two flags instead of one. I guess we could have a two-step process, where you first detect if the sink and sink-input have support for PASSTHROUGH, and then in a second step you verify that the 'subtype' (iec958 or mp3) is compatible. The logic for rejecting connections is the same... You only need one last step to make sure types are compatible. > There would of course be a standard implementation for sinks that don't > do any "strange" stuff. I thought individual sink implementations could > choose to amend the standard logic, but actually I'm not sure how it > could be done without duplicating code. > > Giving it a second thought, the "can this sink input be connected to > this sink" question can be thought equally well as a method of sinks or > sink inputs, or even as a plain old independent function. So, doing it > like you do it in your patch is fine by me (just don't use "iec958" > where the logic isn't really bound to the exact format). As I said above, we can have a first pass implemented in the core that checks things are fine, then a second pass implemented by sinks who support passthrough mode to check fine-grained compatibility. >> > The NOVOLUME flags can be exported to clients, so they can choose to not >> > show any volume controls. Legacy clients should get the >> > PA_ERR_NOTSUPPORTED error when trying to change the volume of streams or >> > sinks that have the NOVOLUME flag. >> >> Yes the volume needs more work. I don't really understand all this >> code through, so for now I disabled the set-volume() routines without >> notifying the client. You end-up in the situation where pavucontrol >> can change the volume but nothing happens, this is not user-friendly. >> Is this NOVOLUME flag an existing one, or something that would need to be added? > > It needs to be added. There's already a detection in the mixer code that the hw_volume is available or not. Maybe we can use this as well. _______________________________________________ pulseaudio-discuss mailing list <a ymailto="mailto:pulseaudio-discuss@mail.0pointer.de" href="mailto:pulseaudio-discuss@mail.0pointer.de">pulseaudio-discuss@mail.0pointer.de</a> <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> </div></div> </div> </body></html>