0002503: audio outputs are not kept in sync with each other

(0004317)
unK (reporter)
2009-08-30 01:47

ugh, I forgot. I'm using alsa as audio output.

(0004650)
metyl (developer)
2009-10-26 03:07
edited on: 2009-10-26 03:09

you should read more not only
2048*25*1(channels) = 50KB/s

the real 44100Hz/16bit/stereo is
44100 * 2(channels)*2(16bits) = 176400 bytes/sec = approx 173 KB/s
or you're 44100Hz/16bit/mono is
44100 * 1(channel)*2(16bits) = 88200 bytes/sec = approx 86 KB/s

i assume this is why your fifo gets full, you're not reading fast enough from the fifo output

(0004651)
unK (reporter)
2009-10-26 04:52

Not really.

I read 2048 samples (which are 16bits long), not bytes. And since 25*2048 > 44100, I am collecting all data from the fifo. Besides, the thing is that visualization forwards sound, not the other way around. It's delayed only if I *try* to read less than 2048.

(0004652)
metyl (developer)
2009-10-26 05:14

ah so you telling me that fifo outputs data faster than alsa then ? Or ?
In fifo output a timer is implemented to ouput data at configured audio output rate (and framesize).

So maybe alsa uses too much buffering or the timer in fifo output does not work well (but i think it works well). I'm still very unsure what delay effect do you see.

(0004654)
unK (reporter)
2009-10-26 10:23

"ah so you telling me that fifo outputs data faster than alsa then ?"
It seems so. But it can be also the case that alsa processes data slower than ncmpcpp is parsing and drawing them, I'm not sure.

"I'm still very unsure what delay effect do you see."
After a few minutes of playing fifo and alsa seem to desychronize, i.e you can "see" sound event (e.g. beat) in a visualizer a moment before you can hear it. This delay seems to grow linearly with the time mpd is playing.

(0004655)
cirrus (administrator)
2009-10-26 10:28

That's because both outputs may be at a different position in the chunk queue.

MPD does not guarantee that outputs are synchronous. Any timing assumptions made by ncmpcpp are invalid.

(0004656)
unK (reporter)
2009-10-26 10:56
edited on: 2009-10-26 10:57

"MPD does not guarantee that outputs are synchronous."
Well, that's what this bug is about, isn't it? It should guarantee it.

(0004657)
cirrus (administrator)
2009-10-26 11:00

Why is that a bug? And why should MPD guarantee that?

(0004658)
metyl (developer)
2009-10-26 11:25
edited on: 2009-10-26 11:26

i dont understand this either. why some audio outpus are using timer to asure constant output rate ? what would happen if this timer is maintained on every output e.g. alsa ? Can it skip some data due not exactly isochronous timing? It is very hard to synchonize outputs because of various buffering used by corresponding outputs. I haven't thought that the visualization could be so hard to synchronize....

(0004659)
cirrus (administrator)
2009-10-26 11:31

To keep outputs in sync, you not only have to solve the chunk queue thing inside MPD, you also have to know the latency of every audio output (including the latency of the client library plus the hardware latency), and of course the client has to include the latency of the MPD connection. This is quite a difficult problem.

Right now, JACK is the only audio output which can measure its latency (though MPD doesn't use this information, because MPD has never cared about latency).

(0004660)
unK (reporter)
2009-10-26 13:19

I think I discovered something interesting. If a client will disable and enable output that provides data for visualization, the delay is gone - sound and visualization are in sync again.

(0004664)
cirrus (administrator)
2009-10-27 03:31

Closing, because submitter didn't explain why this (undefined) behavior is a bug.

(0004666)
unK (reporter)
2009-10-27 12:18

It's a bug because with desynchronized outputs any attempt to create a visualizer for mpd is about to fail, since nobody wants a visualizer that is not synchronized with the sound. And because of the above workaround I described I believe it can be fixed in mpd without any special effort.

(0004667)
cirrus (administrator)
2009-10-27 12:31

What you describe is not a documented or supported use case, and therefore failure to do so is not a bug.

(0004668)
unK (reporter)
2009-10-27 12:49
edited on: 2009-10-27 12:50

So it's undefined behavior, that makes creating a visualization software that works without hacks impossible, therefore it's a limitation and should be make "defined" in a way that'll allow it.

(0004669)
cirrus (administrator)
2009-10-27 12:58

Submit a patch which implements that, and includes documentation.

(0004820)
Avuton Olrich (administrator)
2009-11-05 09:35

FWIW, not implying that I know all, by any means, but this is an impossible bug to fix in the first place, it can be optimized, but time over a network is always spotty, then time to get through the sound card.. it all just seems like an impossible dream to have outputs that are in sync.

(0004872)
metyl (developer)
2009-11-11 11:27

I think it would be interesting to add possibility to for master/slave architecture for outputs so that music chunk data of the to "slave" output will be only sent after it was processed by "master" output.
This would ensure that visualization will get only data already sent to selected master hardware to which takes moreless the same time to process it). This assumes that network latency is near zero (few ms), which is almost always true for LANs.

Notes
(0004317) unK (reporter) 2009-08-30 01:47	ugh, I forgot. I'm using alsa as audio output.

(0004650) metyl (developer) 2009-10-26 03:07 edited on: 2009-10-26 03:09	you should read more not only 2048251(channels) = 50KB/s the real 44100Hz/16bit/stereo is 44100 * 2(channels)2(16bits) = 176400 bytes/sec = approx 173 KB/s or you're 44100Hz/16bit/mono is 44100 1(channel)*2(16bits) = 88200 bytes/sec = approx 86 KB/s i assume this is why your fifo gets full, you're not reading fast enough from the fifo output

(0004651) unK (reporter) 2009-10-26 04:52	Not really. I read 2048 samples (which are 16bits long), not bytes. And since 252048 > 44100, I am collecting all data from the fifo. Besides, the thing is that visualization forwards sound, not the other way around. It's delayed only if I try* to read less than 2048.

(0004652) metyl (developer) 2009-10-26 05:14	ah so you telling me that fifo outputs data faster than alsa then ? Or ? In fifo output a timer is implemented to ouput data at configured audio output rate (and framesize). So maybe alsa uses too much buffering or the timer in fifo output does not work well (but i think it works well). I'm still very unsure what delay effect do you see.

(0004654) unK (reporter) 2009-10-26 10:23	"ah so you telling me that fifo outputs data faster than alsa then ?" It seems so. But it can be also the case that alsa processes data slower than ncmpcpp is parsing and drawing them, I'm not sure. "I'm still very unsure what delay effect do you see." After a few minutes of playing fifo and alsa seem to desychronize, i.e you can "see" sound event (e.g. beat) in a visualizer a moment before you can hear it. This delay seems to grow linearly with the time mpd is playing.

(0004655) cirrus (administrator) 2009-10-26 10:28	That's because both outputs may be at a different position in the chunk queue. MPD does not guarantee that outputs are synchronous. Any timing assumptions made by ncmpcpp are invalid.

(0004656) unK (reporter) 2009-10-26 10:56 edited on: 2009-10-26 10:57	"MPD does not guarantee that outputs are synchronous." Well, that's what this bug is about, isn't it? It should guarantee it.

(0004657) cirrus (administrator) 2009-10-26 11:00	Why is that a bug? And why should MPD guarantee that?

(0004658) metyl (developer) 2009-10-26 11:25 edited on: 2009-10-26 11:26	i dont understand this either. why some audio outpus are using timer to asure constant output rate ? what would happen if this timer is maintained on every output e.g. alsa ? Can it skip some data due not exactly isochronous timing? It is very hard to synchonize outputs because of various buffering used by corresponding outputs. I haven't thought that the visualization could be so hard to synchronize....

(0004659) cirrus (administrator) 2009-10-26 11:31	To keep outputs in sync, you not only have to solve the chunk queue thing inside MPD, you also have to know the latency of every audio output (including the latency of the client library plus the hardware latency), and of course the client has to include the latency of the MPD connection. This is quite a difficult problem. Right now, JACK is the only audio output which can measure its latency (though MPD doesn't use this information, because MPD has never cared about latency).

(0004660) unK (reporter) 2009-10-26 13:19	I think I discovered something interesting. If a client will disable and enable output that provides data for visualization, the delay is gone - sound and visualization are in sync again.

(0004664) cirrus (administrator) 2009-10-27 03:31	Closing, because submitter didn't explain why this (undefined) behavior is a bug.

(0004666) unK (reporter) 2009-10-27 12:18	It's a bug because with desynchronized outputs any attempt to create a visualizer for mpd is about to fail, since nobody wants a visualizer that is not synchronized with the sound. And because of the above workaround I described I believe it can be fixed in mpd without any special effort.

(0004667) cirrus (administrator) 2009-10-27 12:31	What you describe is not a documented or supported use case, and therefore failure to do so is not a bug.

(0004668) unK (reporter) 2009-10-27 12:49 edited on: 2009-10-27 12:50	So it's undefined behavior, that makes creating a visualization software that works without hacks impossible, therefore it's a limitation and should be make "defined" in a way that'll allow it.

(0004669) cirrus (administrator) 2009-10-27 12:58	Submit a patch which implements that, and includes documentation.

(0004820) Avuton Olrich (administrator) 2009-11-05 09:35	FWIW, not implying that I know all, by any means, but this is an impossible bug to fix in the first place, it can be optimized, but time over a network is always spotty, then time to get through the sound card.. it all just seems like an impossible dream to have outputs that are in sync.

(0004872) metyl (developer) 2009-11-11 11:27	I think it would be interesting to add possibility to for master/slave architecture for outputs so that music chunk data of the to "slave" output will be only sent after it was processed by "master" output. This would ensure that visualization will get only data already sent to selected master hardware to which takes moreless the same time to process it). This assumes that network latency is near zero (few ms), which is almost always true for LANs.

Issue History
Date Modified	Username	Field	Change
2009-08-30 01:42	unK	New Issue
2009-08-30 01:42	unK	Status	new => assigned
2009-08-30 01:42	unK	Assigned To	=> cirrus
2009-08-30 01:47	unK	Note Added: 0004317
2009-10-26 03:07	metyl	Note Added: 0004650
2009-10-26 03:08	metyl	Issue Monitored: metyl
2009-10-26 03:09	metyl	Note Edited: 0004650
2009-10-26 04:52	unK	Note Added: 0004651
2009-10-26 05:14	metyl	Note Added: 0004652
2009-10-26 10:23	unK	Note Added: 0004654
2009-10-26 10:28	cirrus	Note Added: 0004655
2009-10-26 10:56	unK	Note Added: 0004656
2009-10-26 10:57	unK	Note Edited: 0004656
2009-10-26 11:00	cirrus	Note Added: 0004657
2009-10-26 11:25	metyl	Note Added: 0004658
2009-10-26 11:26	metyl	Note Edited: 0004658
2009-10-26 11:31	cirrus	Note Added: 0004659
2009-10-26 13:19	unK	Note Added: 0004660
2009-10-27 03:31	cirrus	Note Added: 0004664
2009-10-27 03:31	cirrus	Status	assigned => closed
2009-10-27 03:31	cirrus	Resolution	open => won't fix
2009-10-27 12:18	unK	Note Added: 0004666
2009-10-27 12:18	unK	Status	closed => feedback
2009-10-27 12:18	unK	Resolution	won't fix => reopened
2009-10-27 12:31	cirrus	Note Added: 0004667
2009-10-27 12:49	unK	Note Added: 0004668
2009-10-27 12:50	unK	Note Edited: 0004668
2009-10-27 12:58	cirrus	Note Added: 0004669
2009-10-27 12:58	cirrus	Assigned To	cirrus =>
2009-11-05 09:33	Avuton Olrich	Severity	minor => feature
2009-11-05 09:33	Avuton Olrich	Status	feedback => acknowledged
2009-11-05 09:33	Avuton Olrich	Resolution	reopened => open
2009-11-05 09:35	Avuton Olrich	Note Added: 0004820
2009-11-11 11:27	metyl	Note Added: 0004872

Relationships