Hi,
Miah Gregory wrote:
Hi,
Running from week old SVN (planning to upgrade tonight).
I've had a search of the various mailing lists and asked on IRC, but
no-one's seen this problem before, so I'd like some help in debugging
it. Basically the problem is that when you switch tracks in mythmusic,
either manually whilst one is playing, or automatically as each track
ends, there's around a 10 second delay during which the front end is
unresponsive, cpu load is fairly minimal, and if a track was playing at
the time, around half a second of audio loops constantly for around 10
seconds. After this delay, the next track starts successfully.
I straced the process and believe that mythmusic was hanging whilst
closing the filehandle to /dev/dsp - has anyone seen this before? My
suspicion is that the audio code isn't closing down /dev/dsp properly,
eg. unmapping buffers or whatever, and hence the close() hangs to allow
the buffers to all empty or something?
Very occasionally, mythmusic has crashed whilst attempting the track
change, but I've been so far unable to reproduce this in a debugger.
Any help to continue debugging would be appreciated (on irc as mace if
that's more convenient).
I'm fairly out of touch with the mythmusic code since I've not been
hacking on it for a while now.
There is not reason (that I can think of) as to shy MythMusic /should/
be closing down /dev/dsp on a track change. We only need to flush our
own buffer and then pipe in new data. Unless there is soem sort of
sample rate change this shouldn't be a problem.
Have you tried using both OSS and Alsa output?
Personally, I've never seen this behaviour myself, so if you can work
out how to reliably reporoduce it it would be a bonus.
Col.
--
+------------------------+
| Colin Guthrie |
+------------------------+
| myth(at)colin.guthr.ie |
| http://colin.guthr.ie/ |
+------------------------+
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
