Re: [pulseaudio-discuss] [PATCH] tunnel-{sink, source}-new: Fix assertion when used with loopback or combine-sink
On Sat, 2017-08-12 at 22:29 +0200, Georg Chini wrote: > Currently pulseaudio crashes with an assertion in > pa_rtpoll_item_new_asyncmsgq_read() > or pa_rtpoll_item_new_asyncmsgq_write() if a loopback is applied to a > tunnel-new > sink or source, because tunnel-{sink,source}-new do not set > thread_info.rtpoll. > The same applies to module-combine-sink and module-rtp-recv. > > This patch is not a complete fix for the problem but provides a temporary > band-aid > by initializing thread_info.rtpoll properly. The rtpoll created is never run, > but > loopback and combine-sink nevertheless work, see comments in the code. > > This patch does not work for module-rtp-recv, but using rtp-recv with a remote > sink does not seem to make a lot of sense anyway. > > Bug link: https://bugs.freedesktop.org/show_bug.cgi?id=73429 > --- > src/modules/module-tunnel-sink-new.c | 15 +++ > src/modules/module-tunnel-source-new.c | 12 > 2 files changed, 27 insertions(+) Thanks! Pushed to next. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio Network Sink: Respect alternative sample rate and format
On Thu, 2017-08-10 at 20:33 +0200, Maximilian Böhm wrote: > A bit unlucky but at least now I know that the tunnel sink doesn't > switch the sample rate – after you initiate a server connection, > right? So, to be sure, what happens when I start a 48 kHz stream on > my client? The tunnel sample rate from the client to the server is determined at the time you load module-tunnel-sink. The rate is based on what you configured with the module arguments, or if you didn't configure anything, then it's the default rate that is configured in the client machine's daemon.conf. If the tunnel rate is 44.1 kHz, and you play a 48 kHz stream to the tunnel sink, resampling will happen on the client machine. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/3] core: add generic message interface
On 16.08.2017 16:56, Tanu Kaskinen wrote: On Sun, 2017-08-06 at 15:29 +0200, Georg Chini wrote: On 06.08.2017 07:26, Tanu Kaskinen wrote: On Sat, 2017-08-05 at 21:32 +0200, Georg Chini wrote: On 05.08.2017 13:37, Tanu Kaskinen wrote: On Fri, 2017-08-04 at 15:37 +0200, Georg Chini wrote: This patch adds a new feature to the core which allows to exchange messages between objects. An object can register/unregister a message handler with pa_core_message_handler_{register, unregister}() while any other object can send a message to the handler using the pa_core_send_message() function. A message has 5 arguments (apart from passing the core): recipient: The name of the message handler that will receive the message message: message command message_parameters: A string containing additional parameters message_data: void pointer to some parameter structure, can be used as alternative to message_parameters response: Pointer to a response string that will be filled by the message handler. The caller is responsible to free the string. The patch is a precondition for the following patches that also allow clients to send messages to pulseaudio objects. Because not every message handler should be visible to clients, a flag was added to the handler structure which allows to mark a handler as public or private. There is no restriction on object names, except that a handler name always starts with a "/". The intention is to use a path-like syntax, for example /core/sink_1 for a sink or /name/instances/index for modules. The exact naming convention still needs to be agreed. Message groups are also implemented, so that a handler can subscribe to a message group using pa_core_message_handler_group_[un]subscribe() to receive messages sent to the group. To distinguish group and handler names, group names lack the leading "/". Some of the code used to implement the message groups was adapted from hook-list.c. Message groups are created/deleted implicitely on subscription/unsubscription. The messaging interface can serve as a full replacement for the current hook system with several advantages: - no need to change header files when a new handler/group is implemented - slightly simpler registration interface - multi-purpose message handlers that can handle multiple events - mesage handlers may also be accessible from the client side We agree that it's good to allow clients to send messages to modules. Unfortunately, in this patch you're assuming that we'll also replace hooks with the same system. Can we please keep things simple and do one change at a time? I'm not enthusiastic about replacing hooks, and I'd rather move on with the client message passing before getting consensus on the hook stuff. For reference, here's a list of unnecessary (from pure client message passing point of view) things I can gather from the commit message: - void pointer argument in message handlers - public/private flag - message groups (signals would seem like a better fit for the purpose anyway) Possibly I am only using the wrong words. Let me put it like that: My intention is not to replace the hooks but to incorporate them into a more general concept. I even used a lot of the code and put it in the new message context. The functionality of the hooks is a subset of the messages concept and is fully preserved. So by replacing hooks with messages, nothing would be lost (at least not intentionally), only the interface would change. Take a look at the second patch of the series for an example. The only disadvantage I can think of is that there is one more lookup step required compared to the hooks when finding the right handler. For starters, the conversion has to be implemented, reviewed, and the new interface has to be learned by everyone. Even if I thought that the message system didn't have any API design problems, it's not clear that the conversion would be worth the effort. I would probably be ok with some new API that allows using one callback for multiple hooks, but I think you'll need to get an ok from Arun too. I won't elaborate on the API design issues now, because I don't think it's good to block the client message passing feature. Why would it be urgent to get the feature implemented? Nobody is pressing us and we are designing a new API. It's not urgent, that's true, but it would be nice to make some progress instead of having things stuck in long discussions because you bundle stuff I don't like with the stuff we already agreed on earlier. So here we have the real reason - you just don't like it. Well, I can't argue with that, but still could not refrain from adding a few comments further below. In my opinion, most of the thinking should go into the design phase to get it right from the start. It's not a good idea to come up with something quick, only to have more work patching it up later. Small incremental changes are generally nicer to work with than big changes. The things under
Re: [pulseaudio-discuss] [PATCH 1/3] core: add generic message interface
On Sun, 2017-08-06 at 15:29 +0200, Georg Chini wrote: > On 06.08.2017 07:26, Tanu Kaskinen wrote: > > On Sat, 2017-08-05 at 21:32 +0200, Georg Chini wrote: > > > On 05.08.2017 13:37, Tanu Kaskinen wrote: > > > > On Fri, 2017-08-04 at 15:37 +0200, Georg Chini wrote: > > > > > This patch adds a new feature to the core which allows to exchange > > > > > messages between objects. An object can register/unregister a message > > > > > handler with pa_core_message_handler_{register, unregister}() while > > > > > any other object can send a message to the handler using the > > > > > pa_core_send_message() function. A message has 5 arguments (apart > > > > > from passing the core): > > > > > > > > > > recipient: The name of the message handler that will receive the > > > > > message > > > > > message: message command > > > > > message_parameters: A string containing additional parameters > > > > > message_data: void pointer to some parameter structure, can be used > > > > > as alternative to message_parameters > > > > > response: Pointer to a response string that will be filled by the > > > > > message handler. The caller is responsible to free the > > > > > string. > > > > > > > > > > The patch is a precondition for the following patches that also allow > > > > > clients to send messages to pulseaudio objects. > > > > > > > > > > Because not every message handler should be visible to clients, a flag > > > > > was added to the handler structure which allows to mark a handler as > > > > > public or private. > > > > > > > > > > There is no restriction on object names, except that a handler name > > > > > always starts with a "/". The intention is to use a path-like syntax, > > > > > for example /core/sink_1 for a sink or /name/instances/index for > > > > > modules. > > > > > The exact naming convention still needs to be agreed. > > > > > > > > > > Message groups are also implemented, so that a handler can subscribe > > > > > to a message group using pa_core_message_handler_group_[un]subscribe() > > > > > to receive messages sent to the group. To distinguish group and > > > > > handler > > > > > names, group names lack the leading "/". Some of the code used to > > > > > implement the message groups was adapted from hook-list.c. Message > > > > > groups are created/deleted implicitely on subscription/unsubscription. > > > > > > > > > > The messaging interface can serve as a full replacement for the > > > > > current > > > > > hook system with several advantages: > > > > > - no need to change header files when a new handler/group is > > > > > implemented > > > > > - slightly simpler registration interface > > > > > - multi-purpose message handlers that can handle multiple events > > > > > - mesage handlers may also be accessible from the client side > > > > > > > > We agree that it's good to allow clients to send messages to modules. > > > > Unfortunately, in this patch you're assuming that we'll also replace > > > > hooks with the same system. Can we please keep things simple and do one > > > > change at a time? I'm not enthusiastic about replacing hooks, and I'd > > > > rather move on with the client message passing before getting consensus > > > > on the hook stuff. > > > > > > > > For reference, here's a list of unnecessary (from pure client message > > > > passing point of view) things I can gather from the commit message: > > > > > > > > - void pointer argument in message handlers > > > > - public/private flag > > > > - message groups (signals would seem like a better fit for the purpose > > > > anyway) > > > > > > > > > > Possibly I am only using the wrong words. Let me put it like that: > > > My intention is not to replace the hooks but to incorporate them > > > into a more general concept. I even used a lot of the code and > > > put it in the new message context. The functionality of the hooks > > > is a subset of the messages concept and is fully preserved. > > > So by replacing hooks with messages, nothing would be lost > > > (at least not intentionally), only the interface would change. > > > Take a look at the second patch of the series for an example. > > > > > > The only disadvantage I can think of is that there is one more > > > lookup step required compared to the hooks when finding > > > the right handler. > > > > For starters, the conversion has to be implemented, reviewed, and the > > new interface has to be learned by everyone. Even if I thought that the > > message system didn't have any API design problems, it's not clear that > > the conversion would be worth the effort. I would probably be ok with > > some new API that allows using one callback for multiple hooks, but I > > think you'll need to get an ok from Arun too. I won't elaborate on the > > API design issues now, because I don't think it's good to block the > > client message passing feature. > > Why would it be urgent to get the feature implemented? Nobody is > pressing us and we are