Re: [Musicpd-dev-team] Pulse mixer
Max Kellermann wrote: Hello Linel, Hi I happened to notice that you already pushed code to your public git repository. I cannot merge this right now, because Viliam has changed the mixer API meanwhile. Yes, I saw this, I'm a little busy this week but I already started to make the changes for the last API version. If you have any patches which should be merged into master, please send a pull request on the mailing list (pull git://git.musicpd.org/pat/mpd.git mixer_pulse, not replying to existing thread or I'll miss it), I'll merge your patches then. If patches get merged early, they will be adapted to all API changes by other developers. If you want the pulse mixer merged, please adapt it to the new API, and submit the new patch. If you create a patch named correct the new output pulse implementation, explain what exactly is corrected. It is not obvious to me, because I don't know pulse. When you submit the new patch, you can fold the correction patch into the initial pulse mixer patch. The patch Begin implementation for pulse mixer is superfluous, because it adds commented code. This does not make sens, and this patch does not introduce any progress. Your patch initializes a pa_threaded_mainloop. Does that introduce overhead? If yes, it must definitely be optional. The whole pulse mixer code should be optional, for those who prefer to use their sound chip's hardware volume control, and those people should not experience any slowdown due to your patches. The pa_threaded_mainloop control the mainloop of pulseaudio. So if the pulse output is not used, there are no reasons to introduce overhead. However I have a problem when a try daemonize mpd, may be the mainloop stay locked. I'll look at it as soon as possible. Max Pat. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Pulse mixer
On 2009/01/13 10:29, Linel Patrice patnathan...@gmail.com wrote: The pa_threaded_mainloop control the mainloop of pulseaudio. So if the pulse output is not used, there are no reasons to introduce overhead. We didn't need the main loop stuff before your patch. I don't know the pulse API, please explain why you're using it now. Is it required for your mixer code? If the user chooses to not use your pulse mixer code (but uses a pulse output), can we switch off the main loop? Max -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Pulse mixer
Max Kellermann wrote: On 2009/01/13 10:29, Linel Patrice patnathan...@gmail.com wrote: The pa_threaded_mainloop control the mainloop of pulseaudio. So if the pulse output is not used, there are no reasons to introduce overhead. We didn't need the main loop stuff before your patch. I don't know the pulse API, please explain why you're using it now. Is it required for your mixer code? If the user chooses to not use your pulse mixer code (but uses a pulse output), can we switch off the main loop? Max You did not need the mainloop cause the mainloop was enclosed in the function of the simple api of pulse. To control the pulse mixer, you need to have the context( struct for connexion) , the mainloop of pulse , and the stream struct. Strictly , I only need a connexion to the server , the mainloop and the name of the stream. But if the output have it, let's use the same pointer and thus use the stream to drive the mixer. It is clear or not? -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
