0002789: Mpd output starts stuttering after playing for a very long time

(0005273)
ComputerDruid (reporter)
2010-01-24 21:22

I forgot to mention: an "mpc pause" in this state takes ~ 1 minute to complete but eventually does pause the audio. A subsequent "mpc play" starts the music again (no stutter).

(0005274)
cirrus (administrator)
2010-01-25 10:25

I had several reports on that, but I could never observe that myself. You could try the following: run MPD with debugging symbols, attach with gdb as soon as you encounter the problem. Then type the following commands, paste the output into this bug report:

p *pc
p *player_buffer

Switch to the thread which runs player_task(), and enter:

p *player
p *player->dc
p *player->dc->pipe
p *player->pipe

(0005278)
ComputerDruid (reporter)
2010-01-26 17:27

I'm somewhat new to gdb, so here's my initial findings:
(gdb) p *pc
Structure has no component named operator*.
(gdb) p *player_buffer
$2 = {chunks = 0xb5477008, num_chunks = 512, available = 0x0, mutex = 0x80faea0, num_allocated = 512}

I haven't been able to find the thread running player_task yet though:
(gdb) info threads
  4 Thread 0xb5476b70 (LWP 5929) 0xb7fe1424 in __kernel_vsyscall ()
  3 Thread 0xb5e7bb70 (LWP 5928) 0xb7fe1424 in __kernel_vsyscall ()
  2 Thread 0xb667cb70 (LWP 5927) 0xb7fe1424 in __kernel_vsyscall ()
* 1 Thread 0xb68bf6d0 (LWP 5924) 0xb7fe1424 in __kernel_vsyscall ()
(gdb) p *player
No symbol "player" in current context.
(gdb) thread 2
[Switching to thread 2 (Thread 0xb667cb70 (LWP 5927))]#0 0xb7fe1424 in __kernel_vsyscall ()
(gdb) p *player
No symbol "player" in current context.
(gdb) thread 3
[Switching to thread 3 (Thread 0xb5e7bb70 (LWP 5928))]#0 0xb7fe1424 in __kernel_vsyscall ()
(gdb) p *player
No symbol "player" in current context.
(gdb) thread 4
[Switching to thread 4 (Thread 0xb5476b70 (LWP 5929))]#0 0xb7fe1424 in __kernel_vsyscall ()
(gdb) p *player
No symbol "player" in current context.

(0005279)
cirrus (administrator)
2010-01-26 17:32

Sorry, should have been "p pc" without asterisk.

Try "thread apply all bt" and see which thread is inside player_thread.c; pick the topmost stack frame inside player_thread.c (e.g. "frame 5"), and then try "p *player" etc. again.

(0005280)
ComputerDruid (reporter)
2010-01-26 17:37
edited on: 2010-01-26 17:39

Another thing:
(gdb) continue
Continuing.

The music starts playing again. Normally. This is weird.

Also, debugging this problem takes forever, since it takes time to trigger.

Let me know how I can improve my use of the debugger or anything else I should check for next time it happens.

Edit: Sorry, I'd already done this by the time you'd answered.

(0005294)
ComputerDruid (reporter)
2010-01-27 17:38

Ok, lets try this again:
(gdb) p *player_buffer
$4 = {chunks = 0xb5477008, num_chunks = 512, available = 0x0, mutex = 0x80fae18, num_allocated = 512}
(gdb) p pc
$5 = {buffer_chunks = 512, buffered_before_play = 51, thread = 0x80f9dc0, notify = {mutex = 0x80b4358,
    cond = 0x80b4398, pending = false}, command = PLAYER_COMMAND_NONE, state = PLAYER_STATE_PLAY,
  error = PLAYER_ERROR_NOERROR, bit_rate = 160, audio_format = {sample_rate = 44100, bits = 24 '\030',
    channels = 2 '\002'}, total_time = 247.431, elapsed_time = 233.794998, next_song = 0x80d9bf0,
  errored_song = 0x0, seek_where = 81, cross_fade_seconds = 0, software_volume = 1024,
  total_play_time = 128751.2439249623}

(gdb) thread 2
[Switching to thread 2 (Thread 0xb667cb70 (LWP 5927))]#0 0xb7fe1424 in __kernel_vsyscall ()
(gdb) frame 4
#4 0x08075c09 in play_next_chunk (arg=0x0) at src/player_thread.c:495
495 if (!audio_output_all_wait(64))
(gdb) p *player
Cannot access memory at address 0x0

A null pointer?

Also in player_thread.c:

(gdb) frame 5
#5 do_play (arg=0x0) at src/player_thread.c:719
719 play_next_chunk(&player);
(gdb) p player
$7 = {pipe = 0x81413f0, buffering = false, decoder_starting = false, paused = false, queued = true,
  song = 0x80c6a18, xfade = XFADE_UNKNOWN, cross_fading = false, cross_fade_chunks = 0, play_audio_format = {
    sample_rate = 44100, bits = 24 '\030', channels = 2 '\002'}, size_to_time = 2.834467120181406e-06}
(gdb) p *player
Structure has no component named operator*.

Anything helpful here?

(0005297)
cirrus (administrator)
2010-01-27 17:49

I don't see a clue just yet.

In that stack frame, use all the "p *player..." commands without the asterisk (it's a local variable here, not a pointer). One day, we'll catch this tricky bug for sure!

(And please include the "thread apply all bt" output)

(0005299)
ComputerDruid (reporter)
2010-01-27 18:13

THIS time I left it suspended, yay (but no music for me, boo)
(gdb) thread apply all bt

Thread 4 (Thread 0xb5476b70 (LWP 5929)):
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb6d3cf96 in poll () from /lib/libc.so.6
#2 0xb6f76727 in ?? () from /usr/lib/libasound.so.2
#3 0xb5476120 in ?? ()
#4 0x00000001 in ?? ()
#5 0xffffffff in ?? ()
#6 0xb547615e in ?? ()
#7 0x0811d040 in ?? ()
#8 0xb6fdcff4 in ?? () from /usr/lib/libasound.so.2
#9 0xb5476178 in ?? ()
#10 0xb6f7667f in ?? () from /usr/lib/libasound.so.2
#11 0x0000000d in ?? ()
#12 0x00000029 in ?? ()
#13 0x00000200 in ?? ()
0000014 0x0813f258 in ?? ()
0000015 0xb6fdcff4 in ?? () from /usr/lib/libasound.so.2
#16 0xb5476210 in ?? ()
#17 0xb5476158 in ?? ()
0000018 0x37fe3338 in ?? ()
0000019 0x0813fad8 in ?? ()
0000020 0x0813f258 in ?? ()
#21 0xb547615e in ?? ()
0000022 0xb5476120 in ?? ()
#23 0x00000000 in ?? ()

Thread 3 (Thread 0xb5e7bb70 (LWP 5928)):
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb6fecf95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x08064d56 in notify_wait (notify=0x809d2c4) at src/notify.c:39
#3 0x0806b69c in need_chunks (decoder=0xb5e7b2c8, is=0xb5e7b304) at src/decoder_internal.c:42
#4 decoder_get_chunk (decoder=0xb5e7b2c8, is=0xb5e7b304) at src/decoder_internal.c:66
#5 0x0806ade6 in decoder_data (decoder=0xb5e7b2c8, is=0xb5e7b304, _data=0xb5e791f4, length=8192,
    data_time=239.020004, bitRate=160, replay_gain_info=0x0) at src/decoder_api.c:282
#6 0x08055fbd in mp3_send_pcm (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1024
#7 mp3_synth_and_send (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1083
#8 mp3_read (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1114
#9 mp3_decode (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1205
#10 0x08069e54 in decoder_plugin_stream_decode (plugin=0x8082880, decoder=0xb5e7b2c8, input_stream=0xb5e7b304)
    at src/decoder_plugin.h:130
#11 decoder_stream_decode (plugin=0x8082880, decoder=0xb5e7b2c8, input_stream=0xb5e7b304)
    at src/decoder_thread.c:55
#12 0x0806a359 in decoder_run_song (arg=0x0) at src/decoder_thread.c:205
#13 decoder_run (arg=0x0) at src/decoder_thread.c:250
0000014 decoder_task (arg=0x0) at src/decoder_thread.c:264
0000015 0xb7f0fefb in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00000000 in ?? ()

Thread 2 (Thread 0xb667cb70 (LWP 5927)):
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb6fecf95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x08064d56 in notify_wait (notify=0x809d34c) at src/notify.c:39
#3 0x0805d356 in audio_output_all_wait (threshold=64) at src/output_all.c:418
---Type <return> to continue, or q <return> to quit---
#4 0x08075c09 in play_next_chunk (arg=0x0) at src/player_thread.c:495
#5 do_play (arg=0x0) at src/player_thread.c:719
#6 player_task (arg=0x0) at src/player_thread.c:773
#7 0xb7f0fefb in ?? () from /usr/lib/libglib-2.0.so.0
#8 0x00000000 in ?? ()

Thread 1 (Thread 0xb68bf6d0 (LWP 5924)):
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb6d3cf96 in poll () from /lib/libc.so.6
#2 0xb7ef866f in g_poll () from /usr/lib/libglib-2.0.so.0
#3 0xb7eec758 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0x080fac00 in ?? ()
#5 0x00000005 in ?? ()
#6 0x00040f04 in ?? ()
#7 0x080fac00 in ?? ()
#8 0x00000006 in ?? ()
#9 0x00000001 in ?? ()
#10 0x00000000 in ?? ()

Not sure which frame you meant, so frame 4 stuff (doesn't seem right):
(gdb) frame 4
#4 0x08075c09 in play_next_chunk (arg=0x0) at src/player_thread.c:495
495 if (!audio_output_all_wait(64))
(gdb) p player
$9 = <value optimized out>
(gdb) p player->dc
There is no member named dc.
(gdb) p player.dc
There is no member named dc.

And some frame 5 stuff:
(gdb) frame 5
#5 do_play (arg=0x0) at src/player_thread.c:719
719 play_next_chunk(&player);
(gdb) p player
$10 = {pipe = 0x81413f0, buffering = false, decoder_starting = false, paused = false, queued = true,
  song = 0x80c6a18, xfade = XFADE_UNKNOWN, cross_fading = false, cross_fade_chunks = 0, play_audio_format = {
    sample_rate = 44100, bits = 24 '\030', channels = 2 '\002'}, size_to_time = 2.834467120181406e-06}
(gdb) p player->dc
There is no member named dc.
(gdb) p player->pipe
$11 = (struct music_pipe *) 0x81413f0
(gdb) p player->dc->pipe
There is no member named dc.

Anything useful here?

(0005300)
cirrus (administrator)
2010-01-27 18:17

Sorry - should have been "p *player.dc", "p *player.pipe", "p *player.dc->pipe"

(0005301)
cirrus (administrator)
2010-01-27 18:20

What I can see is that the decoder pauses because the buffer is full - waiting for the the ALSA plugin to finish playing. Unfortunately, the backtrace of the output thread is not readable, can't see what it's doing. Is it possible for you to install a debugging-enabled non-optimized version of libasound?

(0005302)
ComputerDruid (reporter)
2010-01-27 18:21

Ah, pointers. Not quite though:
(gdb) frame 5
#5 do_play (arg=0x0) at src/player_thread.c:719
719 play_next_chunk(&player);
(gdb) p *player.dc
There is no member named dc.
(gdb) p *player.pipe
$12 = {head = 0xb564cbd0, tail_r = 0xb56369c0, size = 448, mutex = 0x80faea0, audio_format = {sample_rate = 44100,
bits = 24 '\030', channels = 2 '\002'}}

(0005303)
cirrus (administrator)
2010-01-27 18:27

Try to strace the output thread (strace -o /tmp/trace -p 5929) for a minute or so, send me the file /tmp/trace to max@duempel.org

The output thread's buffer is surprisingly small, I could imagine libasound is blocking for some reason, and it might not be a MPD issue after all.

(0005304)
ComputerDruid (reporter)
2010-01-27 18:44

It might not be an mpd bug, but we have to look here first to figure out what it's doing. Thanks for the help so far.

It won't let me strace the program, I think because gdb is attached.

# strace -p 5924
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

I think I'll restart mpd in a bit (without gdb), wait for this to trigger again, then do the strace. Unless there's an easier way to do this?

(0005325)
cirrus (administrator)
2010-02-04 07:10

Closing because it turned out to be an ALSA (dmix) bug. Disabling dmix fixes the symptoms.

Notes
(0005273) ComputerDruid (reporter) 2010-01-24 21:22	I forgot to mention: an "mpc pause" in this state takes ~ 1 minute to complete but eventually does pause the audio. A subsequent "mpc play" starts the music again (no stutter).

(0005274) cirrus (administrator) 2010-01-25 10:25	I had several reports on that, but I could never observe that myself. You could try the following: run MPD with debugging symbols, attach with gdb as soon as you encounter the problem. Then type the following commands, paste the output into this bug report: p pc p player_buffer Switch to the thread which runs player_task(), and enter: p player p player->dc p player->dc->pipe p player->pipe

(0005278) ComputerDruid (reporter) 2010-01-26 17:27	I'm somewhat new to gdb, so here's my initial findings: (gdb) p pc Structure has no component named operator. (gdb) p player_buffer $2 = {chunks = 0xb5477008, num_chunks = 512, available = 0x0, mutex = 0x80faea0, num_allocated = 512} I haven't been able to find the thread running player_task yet though: (gdb) info threads 4 Thread 0xb5476b70 (LWP 5929) 0xb7fe1424 in __kernel_vsyscall () 3 Thread 0xb5e7bb70 (LWP 5928) 0xb7fe1424 in __kernel_vsyscall () 2 Thread 0xb667cb70 (LWP 5927) 0xb7fe1424 in __kernel_vsyscall () 1 Thread 0xb68bf6d0 (LWP 5924) 0xb7fe1424 in __kernel_vsyscall () (gdb) p player No symbol "player" in current context. (gdb) thread 2 [Switching to thread 2 (Thread 0xb667cb70 (LWP 5927))]#0 0xb7fe1424 in __kernel_vsyscall () (gdb) p player No symbol "player" in current context. (gdb) thread 3 [Switching to thread 3 (Thread 0xb5e7bb70 (LWP 5928))]#0 0xb7fe1424 in __kernel_vsyscall () (gdb) p player No symbol "player" in current context. (gdb) thread 4 [Switching to thread 4 (Thread 0xb5476b70 (LWP 5929))]#0 0xb7fe1424 in __kernel_vsyscall () (gdb) p player No symbol "player" in current context.

(0005279) cirrus (administrator) 2010-01-26 17:32	Sorry, should have been "p pc" without asterisk. Try "thread apply all bt" and see which thread is inside player_thread.c; pick the topmost stack frame inside player_thread.c (e.g. "frame 5"), and then try "p *player" etc. again.

(0005280) ComputerDruid (reporter) 2010-01-26 17:37 edited on: 2010-01-26 17:39	Another thing: (gdb) continue Continuing. The music starts playing again. Normally. This is weird. Also, debugging this problem takes forever, since it takes time to trigger. Let me know how I can improve my use of the debugger or anything else I should check for next time it happens. Edit: Sorry, I'd already done this by the time you'd answered.

(0005294) ComputerDruid (reporter) 2010-01-27 17:38	Ok, lets try this again: (gdb) p player_buffer $4 = {chunks = 0xb5477008, num_chunks = 512, available = 0x0, mutex = 0x80fae18, num_allocated = 512} (gdb) p pc $5 = {buffer_chunks = 512, buffered_before_play = 51, thread = 0x80f9dc0, notify = {mutex = 0x80b4358, cond = 0x80b4398, pending = false}, command = PLAYER_COMMAND_NONE, state = PLAYER_STATE_PLAY, error = PLAYER_ERROR_NOERROR, bit_rate = 160, audio_format = {sample_rate = 44100, bits = 24 '\030', channels = 2 '\002'}, total_time = 247.431, elapsed_time = 233.794998, next_song = 0x80d9bf0, errored_song = 0x0, seek_where = 81, cross_fade_seconds = 0, software_volume = 1024, total_play_time = 128751.2439249623} (gdb) thread 2 [Switching to thread 2 (Thread 0xb667cb70 (LWP 5927))]#0 0xb7fe1424 in __kernel_vsyscall () (gdb) frame 4 #4 0x08075c09 in play_next_chunk (arg=0x0) at src/player_thread.c:495 495 if (!audio_output_all_wait(64)) (gdb) p player Cannot access memory at address 0x0 A null pointer? Also in player_thread.c: (gdb) frame 5 #5 do_play (arg=0x0) at src/player_thread.c:719 719 play_next_chunk(&player); (gdb) p player $7 = {pipe = 0x81413f0, buffering = false, decoder_starting = false, paused = false, queued = true, song = 0x80c6a18, xfade = XFADE_UNKNOWN, cross_fading = false, cross_fade_chunks = 0, play_audio_format = { sample_rate = 44100, bits = 24 '\030', channels = 2 '\002'}, size_to_time = 2.834467120181406e-06} (gdb) p player Structure has no component named operator. Anything helpful here?

(0005297) cirrus (administrator) 2010-01-27 17:49	I don't see a clue just yet. In that stack frame, use all the "p *player..." commands without the asterisk (it's a local variable here, not a pointer). One day, we'll catch this tricky bug for sure! (And please include the "thread apply all bt" output)

(0005299) ComputerDruid (reporter) 2010-01-27 18:13	THIS time I left it suspended, yay (but no music for me, boo) (gdb) thread apply all bt Thread 4 (Thread 0xb5476b70 (LWP 5929)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6d3cf96 in poll () from /lib/libc.so.6 #2 0xb6f76727 in ?? () from /usr/lib/libasound.so.2 #3 0xb5476120 in ?? () #4 0x00000001 in ?? () #5 0xffffffff in ?? () #6 0xb547615e in ?? () #7 0x0811d040 in ?? () #8 0xb6fdcff4 in ?? () from /usr/lib/libasound.so.2 #9 0xb5476178 in ?? () #10 0xb6f7667f in ?? () from /usr/lib/libasound.so.2 #11 0x0000000d in ?? () #12 0x00000029 in ?? () #13 0x00000200 in ?? () 0000014 0x0813f258 in ?? () 0000015 0xb6fdcff4 in ?? () from /usr/lib/libasound.so.2 #16 0xb5476210 in ?? () #17 0xb5476158 in ?? () 0000018 0x37fe3338 in ?? () 0000019 0x0813fad8 in ?? () 0000020 0x0813f258 in ?? () #21 0xb547615e in ?? () 0000022 0xb5476120 in ?? () #23 0x00000000 in ?? () Thread 3 (Thread 0xb5e7bb70 (LWP 5928)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6fecf95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08064d56 in notify_wait (notify=0x809d2c4) at src/notify.c:39 #3 0x0806b69c in need_chunks (decoder=0xb5e7b2c8, is=0xb5e7b304) at src/decoder_internal.c:42 #4 decoder_get_chunk (decoder=0xb5e7b2c8, is=0xb5e7b304) at src/decoder_internal.c:66 #5 0x0806ade6 in decoder_data (decoder=0xb5e7b2c8, is=0xb5e7b304, _data=0xb5e791f4, length=8192, data_time=239.020004, bitRate=160, replay_gain_info=0x0) at src/decoder_api.c:282 #6 0x08055fbd in mp3_send_pcm (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1024 #7 mp3_synth_and_send (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1083 #8 mp3_read (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1114 #9 mp3_decode (decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder/mad_plugin.c:1205 #10 0x08069e54 in decoder_plugin_stream_decode (plugin=0x8082880, decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder_plugin.h:130 #11 decoder_stream_decode (plugin=0x8082880, decoder=0xb5e7b2c8, input_stream=0xb5e7b304) at src/decoder_thread.c:55 #12 0x0806a359 in decoder_run_song (arg=0x0) at src/decoder_thread.c:205 #13 decoder_run (arg=0x0) at src/decoder_thread.c:250 0000014 decoder_task (arg=0x0) at src/decoder_thread.c:264 0000015 0xb7f0fefb in ?? () from /usr/lib/libglib-2.0.so.0 #16 0x00000000 in ?? () Thread 2 (Thread 0xb667cb70 (LWP 5927)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6fecf95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08064d56 in notify_wait (notify=0x809d34c) at src/notify.c:39 #3 0x0805d356 in audio_output_all_wait (threshold=64) at src/output_all.c:418 ---Type <return> to continue, or q <return> to quit--- #4 0x08075c09 in play_next_chunk (arg=0x0) at src/player_thread.c:495 #5 do_play (arg=0x0) at src/player_thread.c:719 #6 player_task (arg=0x0) at src/player_thread.c:773 #7 0xb7f0fefb in ?? () from /usr/lib/libglib-2.0.so.0 #8 0x00000000 in ?? () Thread 1 (Thread 0xb68bf6d0 (LWP 5924)): #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb6d3cf96 in poll () from /lib/libc.so.6 #2 0xb7ef866f in g_poll () from /usr/lib/libglib-2.0.so.0 #3 0xb7eec758 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0x080fac00 in ?? () #5 0x00000005 in ?? () #6 0x00040f04 in ?? () #7 0x080fac00 in ?? () #8 0x00000006 in ?? () #9 0x00000001 in ?? () #10 0x00000000 in ?? () Not sure which frame you meant, so frame 4 stuff (doesn't seem right): (gdb) frame 4 #4 0x08075c09 in play_next_chunk (arg=0x0) at src/player_thread.c:495 495 if (!audio_output_all_wait(64)) (gdb) p player $9 = <value optimized out> (gdb) p player->dc There is no member named dc. (gdb) p player.dc There is no member named dc. And some frame 5 stuff: (gdb) frame 5 #5 do_play (arg=0x0) at src/player_thread.c:719 719 play_next_chunk(&player); (gdb) p player $10 = {pipe = 0x81413f0, buffering = false, decoder_starting = false, paused = false, queued = true, song = 0x80c6a18, xfade = XFADE_UNKNOWN, cross_fading = false, cross_fade_chunks = 0, play_audio_format = { sample_rate = 44100, bits = 24 '\030', channels = 2 '\002'}, size_to_time = 2.834467120181406e-06} (gdb) p player->dc There is no member named dc. (gdb) p player->pipe $11 = (struct music_pipe *) 0x81413f0 (gdb) p player->dc->pipe There is no member named dc. Anything useful here?

(0005300) cirrus (administrator) 2010-01-27 18:17	Sorry - should have been "p player.dc", "p player.pipe", "p *player.dc->pipe"

(0005301) cirrus (administrator) 2010-01-27 18:20	What I can see is that the decoder pauses because the buffer is full - waiting for the the ALSA plugin to finish playing. Unfortunately, the backtrace of the output thread is not readable, can't see what it's doing. Is it possible for you to install a debugging-enabled non-optimized version of libasound?

(0005302) ComputerDruid (reporter) 2010-01-27 18:21	Ah, pointers. Not quite though: (gdb) frame 5 #5 do_play (arg=0x0) at src/player_thread.c:719 719 play_next_chunk(&player); (gdb) p player.dc There is no member named dc. (gdb) p player.pipe $12 = {head = 0xb564cbd0, tail_r = 0xb56369c0, size = 448, mutex = 0x80faea0, audio_format = {sample_rate = 44100, bits = 24 '\030', channels = 2 '\002'}}

(0005303) cirrus (administrator) 2010-01-27 18:27	Try to strace the output thread (strace -o /tmp/trace -p 5929) for a minute or so, send me the file /tmp/trace to max@duempel.org The output thread's buffer is surprisingly small, I could imagine libasound is blocking for some reason, and it might not be a MPD issue after all.

(0005304) ComputerDruid (reporter) 2010-01-27 18:44	It might not be an mpd bug, but we have to look here first to figure out what it's doing. Thanks for the help so far. It won't let me strace the program, I think because gdb is attached. # strace -p 5924 attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted I think I'll restart mpd in a bit (without gdb), wait for this to trigger again, then do the strace. Unless there's an easier way to do this?

(0005325) cirrus (administrator) 2010-02-04 07:10	Closing because it turned out to be an ALSA (dmix) bug. Disabling dmix fixes the symptoms.

Issue History
Date Modified	Username	Field	Change
2010-01-24 21:20	ComputerDruid	New Issue
2010-01-24 21:20	ComputerDruid	Status	new => assigned
2010-01-24 21:20	ComputerDruid	Assigned To	=> cirrus
2010-01-24 21:22	ComputerDruid	Note Added: 0005273
2010-01-25 10:25	cirrus	Note Added: 0005274
2010-01-26 17:27	ComputerDruid	Note Added: 0005278
2010-01-26 17:32	cirrus	Note Added: 0005279
2010-01-26 17:37	ComputerDruid	Note Added: 0005280
2010-01-26 17:39	ComputerDruid	Note Edited: 0005280
2010-01-27 17:38	ComputerDruid	Note Added: 0005294
2010-01-27 17:49	cirrus	Note Added: 0005297
2010-01-27 18:13	ComputerDruid	Note Added: 0005299
2010-01-27 18:17	cirrus	Note Added: 0005300
2010-01-27 18:20	cirrus	Note Added: 0005301
2010-01-27 18:21	ComputerDruid	Note Added: 0005302
2010-01-27 18:27	cirrus	Note Added: 0005303
2010-01-27 18:44	ComputerDruid	Note Added: 0005304
2010-02-04 07:10	cirrus	Note Added: 0005325
2010-02-04 07:10	cirrus	Status	assigned => closed
2010-02-04 07:10	cirrus	Resolution	open => not fixable

Relationships