[pulseaudio] Bug/Feature Request: Avoid random assignment of pulseaudio sinks to openhab things #12555
Comments
|
This issue has been mentioned on openHAB Community. There might be relevant details there: |
|
Hello, 1- for the network differentiation suggestion : Could you provide the result of the "pactl list sinks" command with the two nearly identical sink created ? I cannot identify a parameter allowing to make a distinction between the network used in the underlying pulseaudio sink implementation. 2- I have, instead of an additional parameter helping to make a distinction, another suggestion : the name parameter could become a "name or description" parameter. Using a unique parameter for both simplifies the code and match another use case I already identified but never address : the pulseaudio naming itself could be somewhat inconsistent. Making it a "weak" requirement help addressing this use case. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: |
|
Hi Gwendal, Ad 1, here is the output of pactl -s localhost list sinks reduced to those two sinks which are the same but only access via ipv4 and ipv6: `Ziel #3 Ziel #12 Ad 2, thank you very much for considering a toggle for defining either the device name or device description as identifier to select the pulseaudio sink as an OpenHAB thing. This solves the problem of having multiple RAOP sinks on one sound device as we can assume that the user will make the description different within the same sound device. Ambiguities could occur if multiple sound devices are in the same network where the description for different audio sinks across different sound devices is the same. Just consider a user naming his audio sink in the living room as "living room" (=description) and an AppleTV in the living room also as "living room". The iOS devices will show the same description for these AirPlay devices, but the icon shown beside "living romm" is different, athere will be an audio symbol or the AppleTV symbol. Nevertheless, such users may be asked to make the description unique across sound devices. Of course, the problem of wrong identification still remains because of doubled sinks due to ipv4/ipv6, as both have the same description. Best regards, |
|
The new binding snapshots discovers the audio sinks based on the identified description. There are only warnings during the OpenHAB startup that the audio sink configured with the description cannot be found, but then afterwards they get ONLINE:
Unfortunately, the audio sinks identified via the descrition cannot playback audio. Invoking a play command causes an exception: |
|
I do not know how whether the pulseaudio binding is able to access an audio sink always under its description or whether the description is only used in the initial assignment of identifying the name of a particular audio sink to link it to an OpenHAB thing. In the latter case, the following remark is relevant: When using the description to identify a particular audio sink, it must be considered that the corresponding name of the audio sink may change over time. Therefore, each time when accessing an audio sink under its description, it must be verified whether the present audio sink that has been originally identified via its description still has the same description. If not, the audio sinks have been re-arranged in and different names have been assigned so that the respective audio sink "moved" to a different audio sink. |
|
Hello, Thanks for the information about your sink. I see that the parameter allowing to make a distinction between the two sink is rather non obvious. I think making a special parameter for the "network-output" parameter is too specific. I updated the snapshot release for you to test.
I fixed this bug in the release. As you said, it was just at startup and had no consequences further.
It was linked to your use case : you have two sinks with the same description (one for IPV4, another for IPV6), and so the binding couldn't choose which one to use. With the new release and the additionalFilter parameter, you should be able to fix this.
It always check the description to access it, so it should be good. |
|
Hi Gwendal, Thank you very much for the new snapshot file. I modified my pulseaudio.things as follows:
The regexp pattern "192.168.4.160" in additionalFilter could be probably narrowed to something like "192\.168\.4\.160", but according to my understanding the given value should match the ip address anyway. Unfortunately, the audio sinks are not detected any longer when specifying the description in the field name and the given ip address in the fieldadditionalFilter:
Best regards, |
|
When I change the additionalFilter by replacing the points in the ip address by backslash point, like additionalFilter="192\.168\.4\.160", I receive the following errors:
|
|
Sorry, my mistake !
The sequence .* means any character, any number of times. |
|
Hi Gwendal, Now the discovery of the audio sinks works! I thought that a partial match would fulfill the regex criterion but the parsing appears to start from ^ until $ so that we need to add the .* in the leading a trailing part. I am sorry to bother you with a further detail: Sometimes, only one of the ipv4 or ipv6 audio sink is detected - for whatever reason. And of course, when trying the updated additionalFilter for the ipv4 address, only the ipv6 sink was present so that it couldnot match th ipv4 filter in the thing definition. Would it be possible to use additionalFilter only in case the description is not unique? Then we should cover all cases... Best regards, |
|
Although the audio sinks are now discovered based on their description, play back of a previously working audio file throws an exception:
|
|
I'm totally depressed (and at a loss). Could you try deleting the following line on your configuration file, as I mentionned here ? In your log, I can see at 20:35:51 that you are trying to play sound, and it's rejected because it cannot find the pulseaudio sink on your pulseaudio server. Could you please make this test : monitor when openHAB says a device if offline/online, and check in the same time if the 'pactl list sinks' still lists it. |
I'm feeling like patching a sinking boat 😅 |
|
Thank you very much for all your efforts. Although we enounter new surprises, thanks to your patches there is phantastic progress. More in detail below:
`Ziel #7 Ziel #8 |
|
Probably also the name field in the pulseaudio binding should support regex so that names could be addressed where the specific value of the enumerator added at the end can be ignored. Example: Unfortunately, only a part of these audio sinks is accessible via pulseaudio and I need to access exactly audio sink 1, meaningless whether ipv4 or ipv6. How can I address them that this conditon is met, although the enumerators in the name always show a different value, but with the guarantee that audio sink 2 always has an enumerator value in its name greater than the enumerator value of audio sink 1. |
OK... I really don't understand what's going on... But if it works, then I'm fine with it !
Seems OK, I will do that : log a warning, grab the first one matching.
Sorry, by looking at the code, I don't understand how it can be possible.
The device name is a property, like the others, and can be matched with the additionalFilters parameter Beside that, I don't know how I can help you more to match your use case. It needs a complex logic outside the scope of a regular binding... New snapshot release (modifications : when several matches, grab the first one + several additionalFilters possible) |
raop_output.description.local => ipv4 audio sink 1 If I understand correctly, is it OK if you take the first name alphabetically ?... |
|
Dear Gwendal, Thank you very much for another snapshot that I can test. :-) Your understanding of selecting the audio sink that matches first in alphabetical order is correct. In my usecase, I have an AirPlay device with description "Wohnzimmer", but which causes creation of up to four pulseaudio sinks. Example 1: raop_output.wohnzimmer.local => ipv4 audio sink 1 I will use name="Wohnzimmer", additionalFilters="raop_output.wohnzimmer.local.*" and then I receive raop_output.wohnzimmer.local as selected audio sink. Example 2: raop_output.wohnzimmer.local => ipv6 audio sink 1 If I want to ensure that only ipv4 with ip 192.168.4.160 is selected, I will use name="Wohnzimmer", additionalFilters="raop_output.wohnzimmer.local.*###.192.168.4.160.". This will result in raop_output.wohnzimmer.local.3 to be selected. With the present implementation of additionalFilters and grabbing the first sink found, you have provided a very flexible solution suited for multiroom audio devices under pulseaudio! Thanks a lot for your patience. Best regards, |
|
I'm glad if it works. I will make a pull request soon. |
To identify the device on the pulseaudio server, you can now use the description instead of the technical id (a.k.a. "name"). To filter furthermore, you can also use the parameter additionalFilters (optional regular expressions that need to match a property value of a device on the pulseaudio server) Closes openhab#12555 Signed-off-by: Gwendal Roulleau <[email protected]>
|
Dear Gwendal, Thank you very much for all your efforts. THe pulseaudio sinks can be properly addressed despite the unambiguous naming issues. However, the issue with getting wrong settings after the naming of a particular pulseaudio sink changes is still relevant. I will open a new ticket for this. Best regards, |
…ice (#12598) * [pulseaudio] Allow flexible parameters to find a given pulseaudio device To identify the device on the pulseaudio server, you can now use the description instead of the technical id (a.k.a. "name"). To filter furthermore, you can also use the parameter additionalFilters (optional regular expressions that need to match a property value of a device on the pulseaudio server) Closes #12555 Signed-off-by: Gwendal Roulleau <[email protected]>
…ice (openhab#12598) * [pulseaudio] Allow flexible parameters to find a given pulseaudio device To identify the device on the pulseaudio server, you can now use the description instead of the technical id (a.k.a. "name"). To filter furthermore, you can also use the parameter additionalFilters (optional regular expressions that need to match a property value of a device on the pulseaudio server) Closes openhab#12555 Signed-off-by: Gwendal Roulleau <[email protected]>
…ice (openhab#12598) * [pulseaudio] Allow flexible parameters to find a given pulseaudio device To identify the device on the pulseaudio server, you can now use the description instead of the technical id (a.k.a. "name"). To filter furthermore, you can also use the parameter additionalFilters (optional regular expressions that need to match a property value of a device on the pulseaudio server) Closes openhab#12555 Signed-off-by: Gwendal Roulleau <[email protected]> Signed-off-by: Andras Uhrin <[email protected]>
…ice (openhab#12598) * [pulseaudio] Allow flexible parameters to find a given pulseaudio device To identify the device on the pulseaudio server, you can now use the description instead of the technical id (a.k.a. "name"). To filter furthermore, you can also use the parameter additionalFilters (optional regular expressions that need to match a property value of a device on the pulseaudio server) Closes openhab#12555 Signed-off-by: Gwendal Roulleau <[email protected]>
Dear Maintainer of the PulseAudio binding,
Thank you very much for providing this binding. When working with this binding, I encountered a random assignment of PulsAudio sinks to a particular OpenHAB thing under OpenHAB 3.2.0. Probably this effect is at the border between bug report and feature request.
The present version of the PulseAudio binding supports an assignment of PulseAudio sinks to a particular Thing in OpenHAB based on the name of the PulseAudio sink:
Thing sink multiroom "Snapcast" @ "Room" [name="alsa_card.pci-0000_00_1f.3", activateSimpleProtocolSink="true", simpleProtocolSinkPort=4711]While this kind of assignment works fine for PulseAudio sinks realized in hardware, it is not possible to uniquely assign a PulseAudio sink that was discovered via the PulseAudio module module-raop-discovery.
The reason is that PulseAudio fails to assign always the same name on such PulseAudio sinks. This random assignment occurs in two cases:
In case you have an ipv4 and ipv6 network enabled, the same PulseAudio sink is discovered twice. As the propagated name of the respective audio sink is identical, PulseAudio appends an enumerator value to the name to make the name unique. But it is only the name that is unique, not the assignment. For example, audio sink raop_output.room.local is detected via the ipv4 network. Then the ipv6 network causes creation of raop_output.room.local.2. This would not be so bad if it is ensured that ipv6 always receives the .2 postfix. Unfortunately, it cannot be ensured that the assignment order is always the same. Therefore, when creating a thing definition in OpenHAB, it is a random assignment whether the ipv4 route will be taken or the ipv6 route. One might argue that this is irrelevant as long as it works. However, in terms of defined network conditions it appears not to be recommandable that the administrator has no way to enforce OpenHAB to use exactly the PulseAudio sink as desired. It is in fact a random choice whether ipv4 or ipv6 is used when addressing the respective OpenHAB thing.
In case you have a RAOP playback device (e.g. an AirPlay Receiver) capable of playing back multiple streams to support speakers in multiple rooms the situation gets even worse. The RAOP playback device shares the same name for all of the provided AirPlay sinks. As reported above for ipv4 / ipv6, each separate AirPlay sink will receive an enumerater value appended to the same name. As the sequence in the discovery of these AirPlay sinks differs upon their detection, we have a random assignment in the OpenHAB things as we can only use the name of the audio sink for the assignment to an OpenHAB thing and the name may differ in the next discovery. Therefore, it is impossible to specify the room where audio is played. It is random.
In view of these issues, I recommend to expand the possibilities to assign a PulseAudio sink to an OpenHAB Thing such that a unique assignment is supported without causing a random selection of a PulseAudio sink will be assigned to an OpenHAB thing in the next discovery.
Let me suggest a possible solution:
a) The assignment between PulseAudio sink and Thing shall consider an optional parameter sinkNetworkType that needs to match the network type (ipv4 or ipv6) of the PulseAudio sink.
b) The assignment between PulseAudio sink and Thing shall consider an optional parameter sinkDescription that needs to match the description of the PulseAudio sink.
c) The assignment between PulseAudio sink and Thing shall consider that the name may only specify the base name of the respective PulseAudio sink without any enumerator. So when specifying the name "raop_output.room.local" it also matches "raop_output.room.local.". The parameters specificed in a) and b) will make the choice unique.
When considering these parameters in the OpenHAB thing definition of a PulseAudio sink, an assignment is possible that remains unique also in the next discovery.
Thank you very much for considering this Feature Request.
Best regards,
Peter
The text was updated successfully, but these errors were encountered: