Re: [pulseaudio-discuss] [RFC] Passthrough support
On Mon, 2011-02-28 at 16:48 -0800, Christ Schlacta wrote: On 2/27/2011 23:29, Arun Raghavan wrote: On Sun, 2011-02-27 at 23:20 -0800, Christ Schlacta wrote: [...] mark settings as optional or required for negotiation. if one or the other can't support an Optional parameter, then it gets replied to as unsupported but continuing. a warning is logged. a mandatory option will cause it to fail with an error message logged (Warning, Remote sink doesn't support required option bitrate. either upgrade Remote Sink, or set bitrate as optional by using optional bitrate foo) or similar. We can do this, but what does it really get us? On the sink side, we know what restrictions we want to place on the input, and it's reasonable to assume anything unspecified is fine (if it's not, it should be specified as a restriction anyway). On the stream side, we're not providing the information as a restriction - we're saying I have this stream, it can be with one of these formats/properties, find me a sink to plug into. What would an optional parameter achieve here? the optional parameter says If you don't have this, it's fine, whereas the mandatory parameter says If you don't have this, then fail. It allows older and newer software to interoperate, if one end of the connection doesn't know about a parameter, it only matters if it's mandatory. the point of the thread was how to allow future changes of parameters without breaking compatibility.. that would achieve that goal, while allowing the two ends to negotiate when to succeed and when to fail, vs. just always trying or always failing. Yes. Just to clarify your point - by an optional parameter you probably mean that for example a sink can declare that it supports any sampling rate. That can be represented for example by making any a special value in the format info property list. I thought first that you meant that every property should be marked explicitly as mandatory or optional, and sinks could say that I support only 48000 Hz sampling rate, but by the way, that's optional, so ignore that, which wouldn't make any sense. So, I thought a clarification was needed... -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 22:52 +0200, Tanu Kaskinen wrote: [...] The set of parameters can potentially grow forever - we don't know what parameters may become relevant in the future. So, I think we should start by documenting the parameters that we know are important today, and define the approach for adding new parameters in the future. When thinking about handling unknown parameters, there are four cases that need to be considered: 1) A sink has a parameter that a client doesn't understand. 2) A source has a parameter that a client doesn't understand. 3) A playback stream has a parameter that a server doesn't understand. 4) A record stream has a parameter that a server doesn't understand. The cases 2 and 3 should be easy - if the receiver of the data doesn't understand a parameter, it means that it doesn't care. The unknown parameter can be just ignored by the negotiation logic, and the final format should have that parameter removed from the proplist. Cases 1 and 4 are more difficult. One possibility would be to fail the negotiation in such case. That would require that the sender always specifies explicitly all parameters that it knows about, even if it can support anything (IIRC I suggested earlier that a missing parameter would mean that everything is supported). Another possibility would be to try anyway, and the receiver would then kill the stream if the actual payload wasn't satisfactory. What should the negotiation logic do in this case? If the unknown parameter is a fixed value, the parameter should probably be left in the final format proplist. What if the unknown parameter is a range or a list? Maybe the negotiation logic should in this case leave the parameter untouched in the final format proplist. I don't know which approach I like more. The first approach (failing) would be cleaner, but the second approach (trying anyway) would work in more cases. I prefer failing if the pa_stream's properties are not a subset of the properties specified by the sink/source. As Pierre mentions, in the foreseeable we're going to be dealing with a limited number of properties (rate, channels, 2-3 codec parameters), so this approach will work until the requirements change in some fundamental way. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On 2/27/2011 22:00, Arun Raghavan wrote: On Tue, 2011-02-22 at 22:52 +0200, Tanu Kaskinen wrote: [...] The set of parameters can potentially grow forever - we don't know what parameters may become relevant in the future. So, I think we should start by documenting the parameters that we know are important today, and define the approach for adding new parameters in the future. When thinking about handling unknown parameters, there are four cases that need to be considered: 1) A sink has a parameter that a client doesn't understand. 2) A source has a parameter that a client doesn't understand. 3) A playback stream has a parameter that a server doesn't understand. 4) A record stream has a parameter that a server doesn't understand. The cases 2 and 3 should be easy - if the receiver of the data doesn't understand a parameter, it means that it doesn't care. The unknown parameter can be just ignored by the negotiation logic, and the final format should have that parameter removed from the proplist. Cases 1 and 4 are more difficult. One possibility would be to fail the negotiation in such case. That would require that the sender always specifies explicitly all parameters that it knows about, even if it can support anything (IIRC I suggested earlier that a missing parameter would mean that everything is supported). Another possibility would be to try anyway, and the receiver would then kill the stream if the actual payload wasn't satisfactory. What should the negotiation logic do in this case? If the unknown parameter is a fixed value, the parameter should probably be left in the final format proplist. What if the unknown parameter is a range or a list? Maybe the negotiation logic should in this case leave the parameter untouched in the final format proplist. I don't know which approach I like more. The first approach (failing) would be cleaner, but the second approach (trying anyway) would work in more cases. I prefer failing if the pa_stream's properties are not a subset of the properties specified by the sink/source. As Pierre mentions, in the foreseeable we're going to be dealing with a limited number of properties (rate, channels, 2-3 codec parameters), so this approach will work until the requirements change in some fundamental way. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss mark settings as optional or required for negotiation. if one or the other can't support an Optional parameter, then it gets replied to as unsupported but continuing. a warning is logged. a mandatory option will cause it to fail with an error message logged (Warning, Remote sink doesn't support required option bitrate. either upgrade Remote Sink, or set bitrate as optional by using optional bitrate foo) or similar. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Sun, 2011-02-27 at 23:20 -0800, Christ Schlacta wrote: [...] mark settings as optional or required for negotiation. if one or the other can't support an Optional parameter, then it gets replied to as unsupported but continuing. a warning is logged. a mandatory option will cause it to fail with an error message logged (Warning, Remote sink doesn't support required option bitrate. either upgrade Remote Sink, or set bitrate as optional by using optional bitrate foo) or similar. We can do this, but what does it really get us? On the sink side, we know what restrictions we want to place on the input, and it's reasonable to assume anything unspecified is fine (if it's not, it should be specified as a restriction anyway). On the stream side, we're not providing the information as a restriction - we're saying I have this stream, it can be with one of these formats/properties, find me a sink to plug into. What would an optional parameter achieve here? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, Feb 22, 2011 at 2:52 PM, Tanu Kaskinen ta...@iki.fi wrote: On Wed, 2011-02-23 at 01:00 +0530, Arun Raghavan wrote: On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote: ok. Looks good. One last comment on proplists. If we don't define a set of mandatory elements, then it's going to be really hard to use this pa_stream_new_extended() routine. How will the client figure out what exactly it needs to send for each format? I was thinking that his would basically develop as convention, though the few basic properties (rate, channels) could be documented along with the pa_encoding_t structure. We can document additional properties (for example bitrate, if some sink ever needs it) as being optional but recommended if available. The set of parameters can potentially grow forever - we don't know what parameters may become relevant in the future. So, I think we should start by documenting the parameters that we know are important today, and define the approach for adding new parameters in the future. I suggest we first work with known mandatory parameters such as sampling freq and nb of channels. The connection fails if these parameters are not set. That's enough to make passthrough work for now. Future extensions can be worked out later. let's not fall into academic debates. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hi Arun, I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. Couple of comments: - There is a miss on the pa_format_info. the sampling frequency is required. The IEC format can be used at various sampling frequencies. Passing just IEC isn't enough to configure the link with the receiver. The number of channels could be 2 by default, but we may need to change this as well for formats like TrueHD or DTS Master. - in case no IEC formats are supported by the sink, what is the returned value? If this is NULL, meaning there is no support, how do we fall back to plain PCM? - in case the routing changes, for example if you plug HDMI or BT, how do we change the connection? Thanks, -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 10:03 -0600, pl bossart wrote: Hi Arun, I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. Couple of comments: - There is a miss on the pa_format_info. the sampling frequency is required. The IEC format can be used at various sampling frequencies. Passing just IEC isn't enough to configure the link with the receiver. The number of channels could be 2 by default, but we may need to change this as well for formats like TrueHD or DTS Master. I figured it'd be best to leave everything but the format in the proplist and then let the sink pick out the properties it needs/expects. This allows us to keep the structure generic and lets sinks specify what/how much information they need to be able to decide whether a format is supported or not. - in case no IEC formats are supported by the sink, what is the returned value? If this is NULL, meaning there is no support, how do we fall back to plain PCM? I assume that the every sink that supports PCM will have one format with PA_ENCODING_PCM in its list of supported formats. With the extended API, I'd like to treat PCM and compressed formats as being equal as much as possible. - in case the routing changes, for example if you plug HDMI or BT, how do we change the connection? The plan is to have clients disconnect and recreate the stream. We could eventually look at a convenience API to do this. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote: Still, I am not clear about the negociation. the client would need to use pa_stream_new_extended with multiple formats, and then get the actual format with get_format_info. If my understanding is correct, then maybe you would need a list of formats instead of just one? Oh, indeed! That was the intention, but I guess I missed putting that in the wiki. Fixed now. ok. Looks good. One last comment on proplists. If we don't define a set of mandatory elements, then it's going to be really hard to use this pa_stream_new_extended() routine. How will the client figure out what exactly it needs to send for each format? I was thinking that his would basically develop as convention, though the few basic properties (rate, channels) could be documented along with the pa_encoding_t structure. We can document additional properties (for example bitrate, if some sink ever needs it) as being optional but recommended if available. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
One last comment on proplists. If we don't define a set of mandatory elements, then it's going to be really hard to use this pa_stream_new_extended() routine. How will the client figure out what exactly it needs to send for each format? I was thinking that his would basically develop as convention, though the few basic properties (rate, channels) could be documented along with the pa_encoding_t structure. We can document additional properties (for example bitrate, if some sink ever needs it) as being optional but recommended if available. To make things clearer I would add the sampling rate as a mandatory property in the RFC. the number of channels may be unknown before you actually decode, and for an IEC format the number of channels seen by PA is 2... -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-23 at 01:00 +0530, Arun Raghavan wrote: On Tue, 2011-02-22 at 13:27 -0600, pl bossart wrote: ok. Looks good. One last comment on proplists. If we don't define a set of mandatory elements, then it's going to be really hard to use this pa_stream_new_extended() routine. How will the client figure out what exactly it needs to send for each format? I was thinking that his would basically develop as convention, though the few basic properties (rate, channels) could be documented along with the pa_encoding_t structure. We can document additional properties (for example bitrate, if some sink ever needs it) as being optional but recommended if available. The set of parameters can potentially grow forever - we don't know what parameters may become relevant in the future. So, I think we should start by documenting the parameters that we know are important today, and define the approach for adding new parameters in the future. When thinking about handling unknown parameters, there are four cases that need to be considered: 1) A sink has a parameter that a client doesn't understand. 2) A source has a parameter that a client doesn't understand. 3) A playback stream has a parameter that a server doesn't understand. 4) A record stream has a parameter that a server doesn't understand. The cases 2 and 3 should be easy - if the receiver of the data doesn't understand a parameter, it means that it doesn't care. The unknown parameter can be just ignored by the negotiation logic, and the final format should have that parameter removed from the proplist. Cases 1 and 4 are more difficult. One possibility would be to fail the negotiation in such case. That would require that the sender always specifies explicitly all parameters that it knows about, even if it can support anything (IIRC I suggested earlier that a missing parameter would mean that everything is supported). Another possibility would be to try anyway, and the receiver would then kill the stream if the actual payload wasn't satisfactory. What should the negotiation logic do in this case? If the unknown parameter is a fixed value, the parameter should probably be left in the final format proplist. What if the unknown parameter is a range or a list? Maybe the negotiation logic should in this case leave the parameter untouched in the final format proplist. I don't know which approach I like more. The first approach (failing) would be cleaner, but the second approach (trying anyway) would work in more cases. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Sat, 2011-02-19 at 13:28 +0200, Tanu Kaskinen wrote: On Fri, 2011-02-18 at 15:11 +0530, Arun Raghavan wrote: Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. I think pa_encoding_t should include PA_ENCODING_ANY for the case where a recording application doesn't care at all about the format. Check. Maybe it would be better to leave out also the channel map from pa_stream_new_extended()? The channel map is relevant only for PCM streams, so putting it in the format info proplist would make sense in my opinion. Agreed. I believe there's no need to alter the pa_stream_connect_* functions in any way. Returning the final format is not possible at the time when the function returns - the API is asynchronous, so the function only sends a request to the server, it doesn't get any response back. When the response eventually comes from the server, the stream state changes to PA_STREAM_READY, which triggers a callback in the client code. That callback can then query the final format. A new function is needed for that: Ah, I /knew/ I was forgetting something when I added that ... const pa_format_info * const *pa_stream_get_format_info(pa_stream *s) My proposal is that the return value is a NULL-terminated list, for supporting sink format querying in the future. For now the list will always contain only one item. Another possibility would be returning just a single format info instance here, and defining a separate function for getting the format list in sink format query cases. Sounds good - I think the NULL-terminated list is preferable. Thanks Tanu, I've updated the page now. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Fri, 2011-02-18 at 15:11 +0530, Arun Raghavan wrote: Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. I think pa_encoding_t should include PA_ENCODING_ANY for the case where a recording application doesn't care at all about the format. Maybe it would be better to leave out also the channel map from pa_stream_new_extended()? The channel map is relevant only for PCM streams, so putting it in the format info proplist would make sense in my opinion. I believe there's no need to alter the pa_stream_connect_* functions in any way. Returning the final format is not possible at the time when the function returns - the API is asynchronous, so the function only sends a request to the server, it doesn't get any response back. When the response eventually comes from the server, the stream state changes to PA_STREAM_READY, which triggers a callback in the client code. That callback can then query the final format. A new function is needed for that: const pa_format_info * const *pa_stream_get_format_info(pa_stream *s) My proposal is that the return value is a NULL-terminated list, for supporting sink format querying in the future. For now the list will always contain only one item. Another possibility would be returning just a single format info instance here, and defining a separate function for getting the format list in sink format query cases. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On 02/18/11 02:41, Arun Raghavan wrote: Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss The alsa driver has creates a /proc entry that lists the coding types available for a particular device. It'd be nice if you would use that for the list of supported coding types (at least for a default). I'm not sure the list would be automatically updated if you unplugged a device and plugged in a new device. The comprehensive list of supported coding types is in alsa-kernel/pci/hda/hda-eld.c. cat /proc/asound/card0/eld#1.0 monitor_present 1 eld_valid 1 monitor_nameTX-SR608 connection_type HDMI eld_version [0x2] CEA-861D or below edid_version[0x3] CEA-861-B, C or D manufacture_id 0xcb3d product_id 0xa62 port_id 0x2 support_hdcp0 support_ai 0 audio_sync_delay0 speakers[0x4f] FL/FR LFE FC RL/RR RLC/RRC sad_count 8 sad0_coding_type[0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 44100 48000 88200 176400 192000 384000 sad0_bits [0xe] 16 20 24 sad1_coding_type[0x1] LPCM sad1_channels 8 sad1_rates [0x1ee0] 44100 48000 88200 176400 192000 384000 sad1_bits [0xe] 16 20 24 sad2_coding_type[0x2] AC-3 sad2_channels 8 sad2_rates [0xe0] 44100 48000 88200 sad2_max_bitrate64 sad3_coding_type[0x7] DTS sad3_channels 8 sad3_rates [0xc0] 48000 88200 sad3_max_bitrate1536000 sad4_coding_type[0x9] DSD (One Bit Audio) sad4_channels 6 sad4_rates [0x40] 48000 sad5_coding_type[0xa] E-AC-3/DD+ (Dolby Digital Plus) sad5_channels 8 sad5_rates [0xc0] 48000 88200 sad6_coding_type[0xb] DTS-HD sad6_channels 8 sad6_rates [0x1ec0] 48000 88200 176400 192000 384000 sad7_coding_type[0xc] MLP (Dolby TrueHD) sad7_channels 8 sad7_rates [0x1480] 88200 192000 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
'Twas brillig, and Arun Raghavan at 18/02/11 09:41 did gyre and gimble: Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. I've maybe missed the discussion, but is it worth having both: pa_stream_new_extended and pa_stream_new_with_proplist_extended Doesn't the former just call the latter with a NULL proplist anyway? While I appreciate the symmetry with the existing API, I'd say avoid the cruft and just call it pa_stream_new_extended() which implies both the format and the proplist. WDYT? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Fri, 2011-02-18 at 03:42 -0700, Kelly Anderson wrote: [...] The alsa driver has creates a /proc entry that lists the coding types available for a particular device. It'd be nice if you would use that for the list of supported coding types (at least for a default). I'm not sure the list would be automatically updated if you unplugged a device and plugged in a new device. The comprehensive list of supported coding types is in alsa-kernel/pci/hda/hda-eld.c. I don't know how it works for HDMI, but if it does update that list based on the receiver, that would be ideal for us, since we should be able to probe that while routing. For S/PDIF, we don't have that option so I guess we'll need to add some additional checkboxes to GUIs so users can select what formats their receiver supports. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Fri, 2011-02-18 at 11:04 +, Colin Guthrie wrote: 'Twas brillig, and Arun Raghavan at 18/02/11 09:41 did gyre and gimble: Hello! On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. I've updated this page with the changes discussed so far (and translated them into the actual API changes that we need). Please take a look and let me know if this looks acceptable. I've maybe missed the discussion, but is it worth having both: pa_stream_new_extended and pa_stream_new_with_proplist_extended Doesn't the former just call the latter with a NULL proplist anyway? While I appreciate the symmetry with the existing API, I'd say avoid the cruft and just call it pa_stream_new_extended() which implies both the format and the proplist. WDYT? Good point - I agree with this. Also, fixed option c in the wiki. :) Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On 02/18/11 06:26, Arun Raghavan wrote: On Fri, 2011-02-18 at 03:42 -0700, Kelly Anderson wrote: [...] The alsa driver has creates a /proc entry that lists the coding types available for a particular device. It'd be nice if you would use that for the list of supported coding types (at least for a default). I'm not sure the list would be automatically updated if you unplugged a device and plugged in a new device. The comprehensive list of supported coding types is in alsa-kernel/pci/hda/hda-eld.c. I don't know how it works for HDMI, but if it does update that list based on the receiver, that would be ideal for us, since we should be able to probe that while routing. Well I know for a fact with hdmi it updates the list when the kernel boots. I'm not sure it gets updated if you switch devices after the kernel is up. I'd say in over 90% of the cases it would be correct. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
Can you elaborate on what you had in mind regarding UIs?
As for UIs, it would probably be nice to have some sort of (hidden by
default) way to show supported format in a sink. Of course, pactl/pacmd
would expose this data too. Other than informative purposes, it would
also make debugging simpler (Hey, my BT headset isn't playing MP3s
automatically .. Can you check if it's actually supported using these
simple steps?)
Yes, the supported formats should be provided in the sink introspection
data. This isn't necessarily relevant when creating streams, though.
Does the assumption, that all sinks support PCM streams, cause some
actual consequences in terms of API? I can't immediately see any
consequences - it seems like an implementation detail that can be
changed later. (I'd like to reserve the possibility to have
passthrough-only sinks in the future, just in case.)
Fair enough. The only niggling API change would be adding a
PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for
each PCM format).
I think the PA_SAMPLE_* enumeration should be left alone. Let it be a
legacy thing for clients that aren't interested in anything else than
PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding
type can be provided with a new enumeration with PA_ENCODING_PCM,
PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for
representing the format set, can contain information saying that
everything is supported.
I didn't get the last bit about what you'd add to the proplist. The
separate enum would work well for the format_info struct, but would you
also suggest extending the API to use the encoding type while setting
up/connecting streams?
I would suggest that the sinks and the clients use the same presentation
for describing the supported formats. It may be a proplist or something
else. In a purely proplist-based solution there may be no need to extend
the stream creation API. However, a purely proplist-based solution would
look hacky to me, but that's a matter of taste.
If I had to decide the format set representation now, I might do it as
follows:
typedef enum pa_encoding {
PA_ENCODING_PCM,
PA_ENCODING_MP3,
...
}
typedef struct pa_format_desc {
pa_encoding_t encoding;
pa_proplist *params; /* string - string: parameter name
* to parameter value. The parameter
* value has syntax for representing
* also lists and ranges. Missing
* parameter means that anything is
* allowed, unknown parameters are
* ignored. */
} pa_format_desc;
Uh, that ended up pretty identical to your pa_format_info proposal, even
though I didn't mean to :) I tried to replace the proplist with a
solution that doesn't require any string parsing, but that ended up very
complicated.
I'm proposing that a new function is added for creating streams that
takes a list of pa_format_desc structs (or maybe pa_format_info is a
better name) instead of sample spec and channel map.
--
Tanu
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble: Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. Yeah, I agree with this statement. It just feels cleaner (my comment about the format being used in the routing would still be an issue here but I agree that it was probably an extreme example that wouldn't really be needed in practice anyway). If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). The client can also choose not to specify any formats. In that case the routing logic can't use the format as input for decisions, but currently there's no such routing logic anyway. After routing is done, the stream enters to a new state, PA_STREAM_ROUTED. In this state the client has to query the set of formats that the sink supports, and decide the final format. When the client sets the format, the stream changes state to PA_STREAM_READY. Hmm, that could work... not really though through the implications of adding a new state here, but I don't think it would cause major headaches downstream. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 10:26 +0200, Tanu Kaskinen wrote:
On Wed, 2011-02-16 at 19:17 +0530, Arun Raghavan wrote:
Can you elaborate on what you had in mind regarding UIs?
As for UIs, it would probably be nice to have some sort of (hidden by
default) way to show supported format in a sink. Of course, pactl/pacmd
would expose this data too. Other than informative purposes, it would
also make debugging simpler (Hey, my BT headset isn't playing MP3s
automatically .. Can you check if it's actually supported using these
simple steps?)
Yes, the supported formats should be provided in the sink introspection
data. This isn't necessarily relevant when creating streams, though.
Ah, right. I was squashing things that aren't really related.
[...]
I would suggest that the sinks and the clients use the same presentation
for describing the supported formats. It may be a proplist or something
else. In a purely proplist-based solution there may be no need to extend
the stream creation API. However, a purely proplist-based solution would
look hacky to me, but that's a matter of taste.
If I had to decide the format set representation now, I might do it as
follows:
typedef enum pa_encoding {
PA_ENCODING_PCM,
PA_ENCODING_MP3,
...
}
typedef struct pa_format_desc {
pa_encoding_t encoding;
pa_proplist *params; /* string - string: parameter name
* to parameter value. The parameter
* value has syntax for representing
* also lists and ranges. Missing
* parameter means that anything is
* allowed, unknown parameters are
* ignored. */
} pa_format_desc;
Uh, that ended up pretty identical to your pa_format_info proposal, even
though I didn't mean to :) I tried to replace the proplist with a
solution that doesn't require any string parsing, but that ended up very
complicated.
Good to see we converged on the same structure. :)
bikeshed Building on the pa_sample_spec naming, pa_stream_spec,
perhaps? /bikeshed
I'm proposing that a new function is added for creating streams that
takes a list of pa_format_desc structs (or maybe pa_format_info is a
better name) instead of sample spec and channel map.
Rethinking this, I'm starting to agree with you and Pierre on this. For
the PA_ENCODING_PCM, the proplist would basically just encode the same
data that's in pa_sample_spec. For other formats, we can add the data we
need.
I'm researching you other proposal and will update the proposal on the
wiki with both these in a while.
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hi Tanu, On Thu, 2011-02-17 at 09:45 +0200, Tanu Kaskinen wrote: On Thu, 2011-02-17 at 02:54 +0530, Arun Raghavan wrote: On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Thanks for the detailed proposal! Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. The client can also choose not to specify any formats. In that case the routing logic can't use the format as input for decisions, but currently there's no such routing logic anyway. After routing is done, the stream enters to a new state, PA_STREAM_ROUTED. In this state the client has to query the set of formats that the sink supports, and decide the final format. When the client sets the format, the stream changes state to PA_STREAM_READY. This sounds pretty clean overall, and after talking to Wim on IRC for a bit, I think we might even be able to do without the no-formats variant of the API. That said, it would be nice to have the last bit as well, so I'll keep it put it down as something to add after the basic bits are done. I've updated the wiki with this version now. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 17/02/11 07:45 did gyre and gimble: Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. Yeah, I agree with this statement. It just feels cleaner (my comment about the format being used in the routing would still be an issue here but I agree that it was probably an extreme example that wouldn't really be needed in practice anyway). If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). I probably didn't understand this correctly, but wouldn't this only be helpful if a new sink comes in exactly between when the routing fails and when you retry? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). Aargh! An unmatched left parenthesis creates an unresolved tension that will stay with me all day! And here you put TWO unmatched parentheses, I'll be tense also tomorrow :( Well, I think I can manage. Anyway, I think this is completely up to the routing logic. It should check the compatibility before doing the routing decision in the first place, if it is somehow aware of the possibility of incompatibility. This way there's no need to go back, which sounds very complicated. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support (extending proplists)
On Wed, 2011-02-16 at 12:33 +, Colin Guthrie wrote:
'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done.
[...]
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
We will need to list explicitly which sampling frequencies are
supported for each format.
This one will probably be somewhat contentious. I was going to put this
information in the format_info structure's proplist so clients can read
and match as they please. There is one stumbling block here in that
proplists do not allow list or range types.
We can either support these by abusing the proplists a bit (for ranges
have a prop.min and prop.max, for lists have prop.num_elements,
prop.elem_0, prop.elem_1, etc.), using simple strings (the way
GstCaps are done) or add first-class list and range types. Listed in
increasing order of effort.
IMO the first is too hacky. The second is quite flexible, but
potentially too generic? The third is the most disruptive, but also most
exactly suited to what we need.
I'm leaning towards the second (string representation like (type) [min,
max] for range and (type) { val1, val2, val3 } for list). In the
current context, the type might be implicit in the key, but since this
literally becomes part of the API, I'd like to plan ahead.
Thoughts?
Random suggestion:
1. The range thing seems simple enough the prop.min and prop.max seems
like an easy enough thing to list and support (perhaps even with a
wrapper function if it saves a bit of sanity checking).
2. The lists are slightly harder, so how about we just support JSON
style syntax here for simple array storage? i.e. ['val1','val2','val\'s
beyond'] ? Again a wrapper function or two can help create/decode
these? Using a format like JSON should be pretty simple and we could
easily enough push out the whole proplist as a single JSON encoded thing
at some point in the future if needed too.
We really should decide on what we need first, I guess :)
I assume that for a given property, the data type is implicitly
understood (this is how things work now).
The other thing to worry about is whether a given property should be
expected to only be either single-valued, a range or a list. This might
not be true - for example when querying a sink, you might get the
supported sample rates as a list, but when connecting, sample rate is
single-valued (we might not use properties to set the sample rate, but
as a generic data structure, I hope you see my point).
From the API perspective, perhaps we could add an enum to represent the
type (single-valued, multi-valued, range), and then have an API to query
this (like pa_proplist_get_type(proplist, key)) that clients would use
if multiple possibilities exist. We can then have API for each type.
Implementation wise, I think it's nicer to just have one key and do some
string parsing for the range case as well.
One thing to note here is that we cannot support lists of strings since,
aiui, JSON requires that strings be enclosed in quotes and we do not
currently do this for single-valued strings. The json.org site is down,
so if I'm wrong, I blame Wikipedia. :)
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
'Twas brillig, and Tanu Kaskinen at 17/02/11 17:17 did gyre and gimble: On Thu, 2011-02-17 at 09:13 +, Colin Guthrie wrote: If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. When this fails, should we go back to the routing system and ask to be routed again, but not to this failing sink? I can see this being a) useful, but b) complicated (not so much complicated on initial connection but complicated when a stream may get re-routed (i.e. when a new, totally unrelated sink comes along, the routing system may re-evaluate it's priority lists and try to move the stream to a higher priority sink (i.e. the one that failed the first time). Aargh! An unmatched left parenthesis creates an unresolved tension that will stay with me all day! And here you put TWO unmatched parentheses, I'll be tense also tomorrow :( Well, I think I can manage. Even more xkcd FTW :) Anyway, I think this is completely up to the routing logic. It should check the compatibility before doing the routing decision in the first place, if it is somehow aware of the possibility of incompatibility. This way there's no need to go back, which sounds very complicated. I think you're right, it would have to know about the compatibility before trying to move. I'm kinda thinking ahead to the priority list approach here, at present this is implemented pretty simply in that the check is simply is the device available, whereas with this new approach we'd have to check is the device available is it compatible with the input. This isn't too much extra logic or work so I think this makes sense. With the likes of passthrough, routing decisions would also have to check to see if the device is available to the degree that it's both present and does not already have a passthrough stream attached (and is thus operating in exclusive mode). So having such extra checks is going to be needed anyway. So I guess this all fits in nicely :) Take care (.. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-16 at 10:10 +0200, Tanu Kaskinen wrote: pulsesink would respond to the query by checking the parameters of the created pa_stream object. If the pipeline building is a heavy process, the stream could be created in corked state. Forget about starting in corked state - it shouldn't matter if the client can't start sending data immediately after creating the stream. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support (extending proplists)
'Twas brillig, and Arun Raghavan at 16/02/11 04:42 did gyre and gimble:
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done.
[...]
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
We will need to list explicitly which sampling frequencies are
supported for each format.
This one will probably be somewhat contentious. I was going to put this
information in the format_info structure's proplist so clients can read
and match as they please. There is one stumbling block here in that
proplists do not allow list or range types.
We can either support these by abusing the proplists a bit (for ranges
have a prop.min and prop.max, for lists have prop.num_elements,
prop.elem_0, prop.elem_1, etc.), using simple strings (the way
GstCaps are done) or add first-class list and range types. Listed in
increasing order of effort.
IMO the first is too hacky. The second is quite flexible, but
potentially too generic? The third is the most disruptive, but also most
exactly suited to what we need.
I'm leaning towards the second (string representation like (type) [min,
max] for range and (type) { val1, val2, val3 } for list). In the
current context, the type might be implicit in the key, but since this
literally becomes part of the API, I'd like to plan ahead.
Thoughts?
Random suggestion:
1. The range thing seems simple enough the prop.min and prop.max seems
like an easy enough thing to list and support (perhaps even with a
wrapper function if it saves a bit of sanity checking).
2. The lists are slightly harder, so how about we just support JSON
style syntax here for simple array storage? i.e. ['val1','val2','val\'s
beyond'] ? Again a wrapper function or two can help create/decode
these? Using a format like JSON should be pretty simple and we could
easily enough push out the whole proplist as a single JSON encoded thing
at some point in the future if needed too.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-16 at 10:10 +0200, Tanu Kaskinen wrote: [...] What if the stream would be created at the time when GStreamer queries the sink format? The query apparently already contains information about the preferred format, otherwise your proposal makes it impossible to do routing decisions based on the sample spec parameter. pulsesink would respond to the query by checking the parameters of the created pa_stream object. If the pipeline building is a heavy process, the stream could be created in corked state. At pipeline setup time, we might not actually have all the information required to set the sample format. With a manual, non-autoplugged pipeline, we just set the elements to READY (that's the bit where we create the context and will do the query) starting from sink to source. TBH, in most cases, I expect the query to be performed with all parameters except maybe stream flags and props as NULL. All those other parameters are only there so that the API doesn't need to change for use-cases that we don't foresee at the moment. So in theory, this means that if you determine routing with some information, but make the connection with more parameters, things might break and you might need to renegotiate (with a limit on how many times you do this). In practice, this shouldn't bite us until there is some significant change to the routing logic, by which time I hope all the pieces for triggering upstream renegotiation from pulsesink will be in place. :) Can you elaborate on what you had in mind regarding UIs? As for UIs, it would probably be nice to have some sort of (hidden by default) way to show supported format in a sink. Of course, pactl/pacmd would expose this data too. Other than informative purposes, it would also make debugging simpler (Hey, my BT headset isn't playing MP3s automatically .. Can you check if it's actually supported using these simple steps?) Does the assumption, that all sinks support PCM streams, cause some actual consequences in terms of API? I can't immediately see any consequences - it seems like an implementation detail that can be changed later. (I'd like to reserve the possibility to have passthrough-only sinks in the future, just in case.) Fair enough. The only niggling API change would be adding a PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for each PCM format). I think the PA_SAMPLE_* enumeration should be left alone. Let it be a legacy thing for clients that aren't interested in anything else than PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding type can be provided with a new enumeration with PA_ENCODING_PCM, PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for representing the format set, can contain information saying that everything is supported. I didn't get the last bit about what you'd add to the proplist. The separate enum would work well for the format_info struct, but would you also suggest extending the API to use the encoding type while setting up/connecting streams? -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Fair enough. The only niggling API change would be adding a PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for each PCM format). I think the PA_SAMPLE_* enumeration should be left alone. Let it be a legacy thing for clients that aren't interested in anything else than PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding type can be provided with a new enumeration with PA_ENCODING_PCM, PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for representing the format set, can contain information saying that everything is supported. I didn't get the last bit about what you'd add to the proplist. The separate enum would work well for the format_info struct, but would you also suggest extending the API to use the encoding type while setting up/connecting streams? I agree with Tanu. Changin the PA_SAMPLE_ enum will open a can of worms since it will create an issue with the byte-to-ms conversion. I tried in the past and it became a nightmare, I had to change code everywhere and had to lie on the results. For the passthrough to work, you want the IEC bistream to look like PCM 16/32 bit stereo so that these conversions are well handled. You would use a tag/flag/proplist to make sure the binary data isn't modified/resampled/etc. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
- I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. One possibly is to connect as PCM, then get a notification from the sink that it can actually support compressed data and then configure the stream. Another possibility is to connect but ask the sink to provide its capabilities in return. We would then have another call to refine the stream configuration. Maybe we should have a short call on this. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hello, On Wed, 2011-02-16 at 09:56 -0600, pl bossart wrote: Fair enough. The only niggling API change would be adding a PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for each PCM format). I think the PA_SAMPLE_* enumeration should be left alone. Let it be a legacy thing for clients that aren't interested in anything else than PCM. pa_format_info doesn't need the pa_sample_spec member. The encoding type can be provided with a new enumeration with PA_ENCODING_PCM, PA_ENCODING_MP3 etc. Then the proplist, or whatever is chosen for representing the format set, can contain information saying that everything is supported. I didn't get the last bit about what you'd add to the proplist. The separate enum would work well for the format_info struct, but would you also suggest extending the API to use the encoding type while setting up/connecting streams? I agree with Tanu. Changin the PA_SAMPLE_ enum will open a can of worms since it will create an issue with the byte-to-ms conversion. I tried in the past and it became a nightmare, I had to change code everywhere and had to lie on the results. For the passthrough to work, you want the IEC bistream to look like PCM 16/32 bit stereo so that these conversions are well handled. You would use a tag/flag/proplist to make sure the binary data isn't modified/resampled/etc. For a quick proof-of-concept, I hacked up a patch to do this by changing PA_SAMPLE_*. The bytes_to_ms conversion is handled correctly, and I disabled monitors to start with, but we'll probably need to make this more intelligent once we squash the passthrough profiles with the non-passthrough ones and attach multiple formats to the sink. http://people.collabora.co.uk/~arun/0001-pulse-Add-sample-formats-for-compressed-formats.patch It's possible I'm missing something, but I did some quick testing on top of your BT passthrough sink as well as with normal ALSA and A2DP+SBC without triggering any asserts. It's certainly not complete (we need to handle things like the Rygel sink that depend on the monitor, but that's not a problem related to this approach). I'm open to going with another approach if that's the consensus, but I thought it would be easiest to just try to code it to prove feasibility one way or the other. Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. One possibly is to connect as PCM, then get a notification from the sink that it can actually support compressed data and then configure the stream. This does solve the problem of connecting and finding the routing changed, but I went with the query API since I think it makes more sense to design around the normal case (assuming that the sink disappearing between query and connect is going to be uncommon). Another possibility is to connect but ask the sink to provide its capabilities in return. We would then have another call to refine the stream configuration. Since the query basically includes all the parameters from pa_stream_new() and pa_stream_connect_playback(), doesn't this amount to the same thing as the current proposal? Maybe we should have a short call on this. Yes, ff we're not able to agree on a solution tomorrow, we could do this over phone/IRC. FWIW, I should be around most of the time except between ~2130 and ~0430 UTC. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
'Twas brillig, and Arun Raghavan at 16/02/11 21:24 did gyre and gimble: On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. Just as a future proofing comment, what if the routing rules used the fact the stream was compressed in it's decision making as to which sink to route it to... ? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Wed, 2011-02-16 at 23:08 +, Colin Guthrie wrote: 'Twas brillig, and Arun Raghavan at 16/02/11 21:24 did gyre and gimble: On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. Just as a future proofing comment, what if the routing rules used the fact the stream was compressed in it's decision making as to which sink to route it to... ? If such routing policy becomes desirable at some point, I think we can still, for now, allow clients not to specify their preferred format when creating streams. If format based policy starts to make bad decisions (wrong routing or declining connections altogether), then it becomes a problem for the applications, and they can be fixed at that point. I don't think we need to make it a problem for the applications yet. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Thu, 2011-02-17 at 02:54 +0530, Arun Raghavan wrote: On Wed, 2011-02-16 at 10:39 -0600, pl bossart wrote: - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). The problem is that you don't know on what sink you will play until you have actually created the pa_stream. The audio policy and routing rules may kick in and if you query before you connect you would end-up with a broken configuration. But the query API includes all the information that we can provide at stream creation/connect time, so things would only break if the query and connect are done with different parameters, or if the sink changed in the period between the two calls. It should be possible for clients to gracefully handle this and renegotiate. Your proposal would probably work well enough in practice, but I still would like more an approach where you create a stream and after it gets routed you finalize the stream format. If routing rules change before the format is decided, the daemon can tear down the stream and inform the client that it happened because of routing change. The client knows now that it should retry. In your proposal the client isn't aware that routing rules have changed, so it doesn't know why the connection fails. Also, even if connecting succeeds, but with different routing, the stream format that the client chooses may be suboptimal. So, my proposal is the following: Sinks have a list of format descriptions. One format description is a tuple consisting of the encoding type and some parameters that are characteristic for that encoding type. Depending on the parameter, a parameter value can be a single value, a range, a list or the parameter may be unset, meaning that anything is allowed. There should also be a special encoding type any, that means that the client supports anything (useful for recording applications that just dump the stream to a file). When a client creates a new stream, it gives a similar list of formats as described above for sinks. The list must cover all formats that the client can support (usually the list contains only one tuple with only fixed parameters). The daemon routes the stream to some sink, and then the daemon takes an intersection of the sink formats and the stream formats. If the resulting set contains exactly one fixed format, then that is used for the stream. If the set contains more options than one fixed format, then the daemon decides the best format using some unspecified algorithm. If the set is empty, then the stream creation fails. The client can also choose not to specify any formats. In that case the routing logic can't use the format as input for decisions, but currently there's no such routing logic anyway. After routing is done, the stream enters to a new state, PA_STREAM_ROUTED. In this state the client has to query the set of formats that the sink supports, and decide the final format. When the client sets the format, the stream changes state to PA_STREAM_READY. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [RFC] Passthrough support
Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. Thanks Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Hi, On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. How about reusing gstreamer formats, so that adding a new format to PA makes it appear automagically in apps using GST (no need to recompile GST) ? Xav ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-15 at 17:47 +0100, Xavier Bestel wrote: Hi, On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. How about reusing gstreamer formats, so that adding a new format to PA makes it appear automagically in apps using GST (no need to recompile GST) ? Tempting as it is ;), we want to keep PA framework-agnostic. Also, in most cases, you will likely need to update pulsesink on the GStreamer side anyway to do some sort of payloading (IEC 61937 in the formats we're talking about now). Cheers, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
How about reusing gstreamer formats, so that adding a new format to PA makes it appear automagically in apps using GST (no need to recompile GST) ? Tempting as it is ;), we want to keep PA framework-agnostic. Also, in most cases, you will likely need to update pulsesink on the GStreamer side anyway to do some sort of payloading (IEC 61937 in the formats we're talking about now). Actually Gstreamer would need to add a set of IEC61937 formats as well. The current IEC968 format exposed in gstreamer can mean either PCM or compressed but doesn't differentiate between, say, AC3 and DTS. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. Thanks Arun, this is a good start. Couple of comments: - change raw to PCM, it's less ambiguous. - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. - I think we need to look at the 'start_move' and 'finish_move' as well. If a reconfiguration to PCM is needed, we may need to wait until the client sends PCM again? - I am not sure the channel map matters for compressed data. The receiver will adjust anyway to the actual number of speakers, e.g. downmix if you use a headset. - you want to add E-AC3 as a basic format. It uses a different IEC syntax - The receiver may support the same format at different sampling frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT). We will need to list explicitly which sampling frequencies are supported for each format. - Changing the monitor is tricky, we may want to keep it but either tag the data as IEC as well, or just zero out. - On deprecating the PA_SINK_INPUT_PASSTHROUGH: yes it can be removed as long as you have some means to signal that the data isn't your ordinary PCM. Extending the pa_sample_spec would break the API, I vote for a proplist here. I am sure others will have some remarks as well. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. Good initiative! My comments: I'm not sure the query function is needed. If its purpose is just to enable stream format negotiation, I'd do it so that when connecting the stream, some representation of the set of formats that the client supports for the new stream would be provided by the client. The representation might be a proplist, or something else. It's then up to the server to select the exact format. The format set representation might support ordering by preference, so that the client would have more control. The final format could then be queried from the pa_stream object. If the representation would be something else than a proplist, then I guess it would be ok to create a special function for creating a passthrough stream. The point of this proposal is that this would avoid two round-trips to the server: first the _get_actual_sink() call and then the _get_sink_info_by_index() call. Does the assumption, that all sinks support PCM streams, cause some actual consequences in terms of API? I can't immediately see any consequences - it seems like an implementation detail that can be changed later. (I'd like to reserve the possibility to have passthrough-only sinks in the future, just in case.) Pierre had a comment about moving streams between compressed and PCM sinks. It seems that we understood the proposal differently. Pierre talks about waiting the client to start sending the correctly formatted data before finishing the move, but isn't the proposal such that there doesn't need to be any waiting logic? When moving is initiated, the stream is actually killed and the client is notified that it should create another stream. I vote for disabling monitor sources altogether for passthrough sinks, at least in the first phase, unless it's trivial to send the compressed data in some way that is actually useful. Sending silence doesn't sound useful to me. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote: Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. Thanks Arun, this is a good start. Couple of comments: Thanks for the detailed review. Responses inline ... - change raw to PCM, it's less ambiguous. Ack. - I am not sure I understand how/when the query would be used. Seems to me like a notification with the formats exposed by the sink currently selected would be more usable. And if a change in routing happens (new accessory, audio policy, etc), the client is informed and can reconfigure to PCM if need be. In this scheme, how would the client first determine what formats are available? The notification will also be required - we can either piggyback in sink, sink-input and card change notifications, or introduce a new one for a change in available formats (I prefer the latter). - I think we need to look at the 'start_move' and 'finish_move' as well. If a reconfiguration to PCM is needed, we may need to wait until the client sends PCM again? Ah, this isn't clear in the proposal at all. As Tanu pointed out, when moving, the client needs to disconnect the existing stream and connect with a new stream anyway. That said, it would be nice to give the client fair warning instead of pulling the stream out from under it's feet. I'll dig in a bit and try to find a more elegant approach here. - I am not sure the channel map matters for compressed data. The receiver will adjust anyway to the actual number of speakers, e.g. downmix if you use a headset. I presume you mean in the query API? I've kept all the arguments we pass to pa_stream_new() and pa_stream_connect_playback() to be future-proof. In most cases, everything but the stream flags and proplist will be NULL, but if, at some point in the future, any of the other parameters start to be used in routing. (not very practical example: if the receiver expects input as a particular channel map, but the compressed data has a different mapping, we would claim to not support that format so the client would have to decode and then remap in PA) - you want to add E-AC3 as a basic format. It uses a different IEC syntax Ack. - The receiver may support the same format at different sampling frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT). We will need to list explicitly which sampling frequencies are supported for each format. [taking this up in a separate thread] - Changing the monitor is tricky, we may want to keep it but either tag the data as IEC as well, or just zero out. Right. - On deprecating the PA_SINK_INPUT_PASSTHROUGH: yes it can be removed as long as you have some means to signal that the data isn't your ordinary PCM. Extending the pa_sample_spec would break the API, I vote for a proplist here. I think we might need to break the API here in order to keep it clean. IMHO it is somewhat hackish to expect clients to set their sample format to s16 stereo + passthrough flag to signal compressed data. Besides UIs will all need to check this flag and the sink input's properties to be able to tell what format is being played. The only real API break is that PA_SAMPLE_MAX will change. I was thinking of something along the lines of: PA_SAMPLE_U8 = 0 ... other PCM formats ... PA_SAMPLE_PCM_MAX ... compressed formats here ... PA_SAMPLE_MAX PA_SAMPLE_INVALID = -1 PA_SAMPLE_PCM_ANY = -2 The last addition (PCM_ANY) is for convenience in the query API (you don't need one pa_format_info for each PCM format, then). -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-15 at 12:11 -0600, pl bossart wrote: How about reusing gstreamer formats, so that adding a new format to PA makes it appear automagically in apps using GST (no need to recompile GST) ? Tempting as it is ;), we want to keep PA framework-agnostic. Also, in most cases, you will likely need to update pulsesink on the GStreamer side anyway to do some sort of payloading (IEC 61937 in the formats we're talking about now). Actually Gstreamer would need to add a set of IEC61937 formats as well. The current IEC968 format exposed in gstreamer can mean either PCM or compressed but doesn't differentiate between, say, AC3 and DTS. We were thinking of doing the payloading in pulsesink since there aren't really any other elements that use this format. In that case, we don't need a new format. If it turns out that a dedicated iec61937 payloader might be generally useful, then we /will/ need to add those new formats. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support (extending proplists)
On Tue, 2011-02-15 at 12:33 -0600, pl bossart wrote:
Please review/comment. Once we have some consensus, I'll send in patches
to actually get this done.
[...]
- The receiver may support the same format at different sampling
frequencies (eg MPEG at 32, 44.1 and 48kHz but not any other for BT).
We will need to list explicitly which sampling frequencies are
supported for each format.
This one will probably be somewhat contentious. I was going to put this
information in the format_info structure's proplist so clients can read
and match as they please. There is one stumbling block here in that
proplists do not allow list or range types.
We can either support these by abusing the proplists a bit (for ranges
have a prop.min and prop.max, for lists have prop.num_elements,
prop.elem_0, prop.elem_1, etc.), using simple strings (the way
GstCaps are done) or add first-class list and range types. Listed in
increasing order of effort.
IMO the first is too hacky. The second is quite flexible, but
potentially too generic? The third is the most disruptive, but also most
exactly suited to what we need.
I'm leaning towards the second (string representation like (type) [min,
max] for range and (type) { val1, val2, val3 } for list). In the
current context, the type might be implicit in the key, but since this
literally becomes part of the API, I'd like to plan ahead.
Thoughts?
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Passthrough support
On Tue, 2011-02-15 at 22:14 +0200, Tanu Kaskinen wrote: On Tue, 2011-02-15 at 22:02 +0530, Arun Raghavan wrote: Hey folks, I've put up a draft proposed API changes to get passthrough support to the point where things Just Work™ for at least the common cases, based on previous discussion on-/off-list: http://pulseaudio.org/wiki/PassthroughSupport Please review/comment. Once we have some consensus, I'll send in patches to actually get this done. Good initiative! My comments: Thanks for the review! I'm not sure the query function is needed. If its purpose is just to enable stream format negotiation, I'd do it so that when connecting the stream, some representation of the set of formats that the client supports for the new stream would be provided by the client. The representation might be a proplist, or something else. It's then up to the server to select the exact format. The format set representation might support ordering by preference, so that the client would have more control. The final format could then be queried from the pa_stream object. If the representation would be something else than a proplist, then I guess it would be ok to create a special function for creating a passthrough stream. The point of this proposal is that this would avoid two round-trips to the server: first the _get_actual_sink() call and then the _get_sink_info_by_index() call. This is doable, and not mutually exclusive with the query API. We could offer this as a simple API for clients that want to offload the negotiation to PA if the need is felt - it would require either breaking API in pa_stream_connect_playback() or adding a variant that takes an array of pa_format_info structs. Having a query makes for a more flexible API, though. For example, it fits more more neatly with the way GStreamer works - you query the sink's format and then build your pipeline from source to sink accordingly. Also, it would probably be good to be able to make this query for UIs. Does the assumption, that all sinks support PCM streams, cause some actual consequences in terms of API? I can't immediately see any consequences - it seems like an implementation detail that can be changed later. (I'd like to reserve the possibility to have passthrough-only sinks in the future, just in case.) Fair enough. The only niggling API change would be adding a PA_FORMAT_PCM_ANY (it would be unwieldy to return one pa_format_info for each PCM format). Pierre had a comment about moving streams between compressed and PCM sinks. It seems that we understood the proposal differently. Pierre talks about waiting the client to start sending the correctly formatted data before finishing the move, but isn't the proposal such that there doesn't need to be any waiting logic? When moving is initiated, the stream is actually killed and the client is notified that it should create another stream. You're right, and I think this still needs some fleshing out though, as I mentioned in another mail. I vote for disabling monitor sources altogether for passthrough sinks, at least in the first phase, unless it's trivial to send the compressed data in some way that is actually useful. Sending silence doesn't sound useful to me. The only potential use I see is possibly for debugging, so I'm fine with disabling it in general. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
