Re: [Musicpd-dev-team] concerns about wakeups
Hi Max, 2009/3/23 Max Kellermann m...@duempel.org: On 2009/03/22 11:43, Kodest kod...@gmail.com wrote: Just tell me when i can check the wakeups again :) Submit a bug report, we'll add it to the 0.15 roadmap. http://musicpd.org/mantis/view.php?id=2183 Is there any docs on how the output mechanism works? I would be interested in how the audio chunks travel among the different threads at the output subsystem, but the code is quite complex. Maybe I can help if i understand this one. (Only maybe because my time is really limited nowadays.) Yes, I've been missing your regular contributions in the past months ;) Basically: the decoder thread feeds music_chunk objects into a music_pipe. The player thread takes them from there, and appends them to the output's music_pipe instance. The output threads now consume them. When all output threads have consumed a music_chunk, it is freed (returned to the music_buffer). The frequent wakeups (supposedly) come from the threads waiting for more chunks, or waiting for enough room in the pipe, or waiting for free chunks in the music_buffer. They're just using g_usleep(10ms) to synchronize, because I havn't had time to think about the proper solution yet (using GCond or struct notify). For most setups (small buffers, low latency), the music_pipe/chunk/buffer code is more efficient than the old method (fully synchronous buffer passing), but for your setup, it's worse. We will optimize MPD for all possible use cases. I tried with default sized alsa buffer (period_size=1024; buffer_size=8192). I get the same amount of wakeups caused by mpd (~950 per sec). Only the number of interrupts changed to 50 per sec from 10. Btw low latency can be achieved through large buffers as well; this could be useful reading: http://0pointer.de/blog/projects/pulse-glitch-free.html I believe it'll take some time to fully understand that code, so if you have little time, I promise to fix it this week. Thanks for the info, I will look at that code too. Regards, Kodest -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] concerns about wakeups
On 2009/03/21 14:20, Kodest kod...@gmail.com wrote: I took a look at powertop yesterday, and found that mpd has begun to generate many wakeups (much more than it used to do before, ~950 per sec). So, I did a bisect and I think I have found the guilty commit: 3291666b570b1d20f59db42936eaa37dbeb9ca65 As far as I see, this is a reorganization in the output system. Please look at this. You're talking about MPD while playing, aren't you? How many wakeups before that commit (while playing)? I know that it's a bit inefficient right now, and the code has several comments XXX synchronize in a better way. I will work on that before the 0.15 release (and before the beta test, that's important). Max -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] concerns about wakeups
Hi Max, 2009/3/22 Max Kellermann m...@duempel.org: On 2009/03/21 14:20, Kodest kod...@gmail.com wrote: I took a look at powertop yesterday, and found that mpd has begun to generate many wakeups (much more than it used to do before, ~950 per sec). So, I did a bisect and I think I have found the guilty commit: 3291666b570b1d20f59db42936eaa37dbeb9ca65 As far as I see, this is a reorganization in the output system. Please look at this. You're talking about MPD while playing, aren't you? Yes, i measured wakeups while mpd was playing mp3s. (Actually mp3s are irrelevant, flac does the same; the problem is not at the input/decoder parts.) How many wakeups before that commit (while playing)? Last good commit (commit ab3d7c29dae44f39df28c85e26b108c44fdbc4bf): mpd doesn't even come up. Only the interrupts can be seen in powertop generated by the sound hw (only ~2-3 per sec, because i use large alsa buffer). I think this is quite good! First bad commit (commit 3291666b570b1d20f59db42936eaa37dbeb9ca65) 95.6% (947.0) mpd : do_nanosleep (hrtimer_wakeup) Last commit at the moment (commit 71cd24954a34bc9fb0fdf6505616ba79b8320a5a) 95.6% (948.3) mpd : do_nanosleep (hrtimer_wakeup) I know that it's a bit inefficient right now, and the code has several comments XXX synchronize in a better way. I will work on that before the 0.15 release (and before the beta test, that's important). Just tell me when i can check the wakeups again :) Is there any docs on how the output mechanism works? I would be interested in how the audio chunks travel among the different threads at the output subsystem, but the code is quite complex. Maybe I can help if i understand this one. (Only maybe because my time is really limited nowadays.) Regards, Kodest -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
