[RFC] hack around desync on OSS pause
Hello, what do you think about attached patch? It fixes the massive desync that happens esp. when doing lots of frame stepping with -ao oss. It is a bit hackish though, and in difference to alsa it will still loose some sound during pause and not play any sound while framestepping. Greetings, Reimar Döffinger
2007/4/29, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
Hello, what do you think about attached patch? It fixes the massive desync that happens esp. when doing lots of frame stepping with -ao oss. It is a bit hackish though, and in difference to alsa it will still loose some sound during pause and not play any sound while framestepping.
I've always thought that the problem is that we actually close the device on pause, instead using the proper ctrl to actually pause it. But so many people insist on that behavior.... To the extend to request it for ao alsa too... (and my attempt to implement it properly was futile;)
Hello, On Sun, Apr 29, 2007 at 01:32:43AM +0300, Ivan Kalvachev wrote:
2007/4/29, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
what do you think about attached patch? It fixes the massive desync that happens esp. when doing lots of frame stepping with -ao oss. It is a bit hackish though, and in difference to alsa it will still loose some sound during pause and not play any sound while framestepping.
I've always thought that the problem is that we actually close the device on pause, instead using the proper ctrl to actually pause it.
According to the documentation I saw there is no functionality to pause in OSS, with some stupid argumentation from someone who probably never actually used it for anything beyond his 50-line-my-own-music-player...
But so many people insist on that behavior.... To the extend to request it for ao alsa too... (and my attempt to implement it properly was futile;)
As far as sync is concerned, I think my proposed patch is "proper". And there are people who requested framestep not to make any noise even with alsa, so it might even be "better" that the "correct" solution, but I'd like to hear other opinions, esp. if someone sees a case where it breaks things (e.g. I think it might cause you to miss one word when you pause in the middle of someone speaking in a film). Greetings, Reimar Döffinger
On Sun, 29 Apr 2007 02:07:09 +0200, Reimar Döffinger scribed:
Hello, On Sun, Apr 29, 2007 at 01:32:43AM +0300, Ivan Kalvachev wrote:
2007/4/29, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
what do you think about attached patch? It fixes the massive
can you make it optional? like -framestep-audio-hack ... this way you dont change current behaviour (reguardless who is right) and anyone that has this problem can use the option. -compn
On Saturday 28 April 2007 at 18:45, Compn wrote:
On Sun, 29 Apr 2007 02:07:09 +0200, Reimar Döffinger scribed:
Hello, On Sun, Apr 29, 2007 at 01:32:43AM +0300, Ivan Kalvachev wrote:
2007/4/29, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
what do you think about attached patch? It fixes the massive
can you make it optional? like -framestep-audio-hack ...
this way you dont change current behaviour (reguardless who is right) and anyone that has this problem can use the option.
I would say, such a philosophy would make create a jungle of parameters in the future. There must be a deterministic way of doing it, is there ? I.e. a well specified way to achieve such a simple audio pause function, like filling the buffer with quiet PCM data and then stop the engine and reset it. AS somebody else said it allready, if it's a driver bug, let 'em fix it. Thats better than to mystify the code. Just my dispensable blabering ;-) Sven
Hello, On Sat, Apr 28, 2007 at 08:45:09PM -0400, Compn wrote:
On Sun, 29 Apr 2007 02:07:09 +0200, Reimar Döffinger scribed:
On Sun, Apr 29, 2007 at 01:32:43AM +0300, Ivan Kalvachev wrote:
2007/4/29, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
what do you think about attached patch? It fixes the massive
can you make it optional? like -framestep-audio-hack ...
this way you dont change current behaviour (reguardless who is right) and anyone that has this problem can use the option.
The question is: can anyone think of any reason why someone would want the current behaviour? What I said about some of the audio being dropped is already the case currently, my patch just inserts the same length of silence instead. Greetings, Reimar Döffinger
On Sun, 29 Apr 2007 09:16:13 +0200 Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
The question is: can anyone think of any reason why someone would want the current behaviour? What I said about some of the audio being dropped is already the case currently, my patch just inserts the same length of silence instead.
I cannot. Actualy anything than the current behavior is better. And don't worry about losing a word. Currently we lose a lot more than one. Attila Kinali -- Linux ist... wenn man einfache Dinge auch mit einer kryptischen post-fix Sprache loesen kann -- Daniel Hottinger
On Sun, Apr 29, 2007 at 02:07:09AM +0200, Reimar Döffinger wrote:
Hello, On Sun, Apr 29, 2007 at 01:32:43AM +0300, Ivan Kalvachev wrote:
2007/4/29, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de>:
what do you think about attached patch? It fixes the massive desync that happens esp. when doing lots of frame stepping with -ao oss. It is a bit hackish though, and in difference to alsa it will still loose some sound during pause and not play any sound while framestepping.
I've always thought that the problem is that we actually close the device on pause, instead using the proper ctrl to actually pause it.
According to the documentation I saw there is no functionality to pause in OSS, with some stupid argumentation from someone who probably never actually used it for anything beyond his 50-line-my-own-music-player...
The functionality is not needed in the driver. Just make ao_oss keep a copy of whatever audio it's submitted, and on pause, check the current delay/position in the buffer, then resubmit those samples after unpause. Or if you just care about the desync issue with multiple framesteps, fix mplayer.c so that it doesn't decode/submit audio at all when the audio timer is ahead of the video timer. Rich
Hello, On Sat, Apr 28, 2007 at 09:02:58PM -0400, Rich Felker wrote: [...]
The functionality is not needed in the driver. Just make ao_oss keep a copy of whatever audio it's submitted, and on pause, check the current delay/position in the buffer, then resubmit those samples after unpause.
Um. Normally you don't advocate code bloat and waste of memory and CPU time (> 2MB/s is a possible value even if you disregard the really insane audio sampling rates and channel counts that are actually possible and in (rare) use), esp. for something that in my uneducated eyes seems almost trivial to do in the driver (though it would conflict with closing the device on pause).
Or if you just care about the desync issue with multiple framesteps, fix mplayer.c so that it doesn't decode/submit audio at all when the audio timer is ahead of the video timer.
I tried this _twice_, I'm not going to propose a third variant any time soon, no sorry. Greetings, Reimar Döffinger
On Sunday 29 April 2007 at 01:28, Reimar Döffinger wrote:
Hello, On Sat, Apr 28, 2007 at 09:02:58PM -0400, Rich Felker wrote: [...]
The functionality is not needed in the driver. Just make ao_oss keep a copy of whatever audio it's submitted, and on pause, check the current delay/position in the buffer, then resubmit those samples after unpause.
Um. Normally you don't advocate code bloat and waste of memory and CPU time (> 2MB/s is a possible value even if you disregard the really insane audio sampling rates and channel counts that are actually possible and in (rare) use), esp. for something that in my uneducated eyes seems almost trivial to do in the driver (though it would conflict with closing the device on pause).
Well, last time I programmed an QNX a/v out driver thread using ALSA 0.5 ;-), it was possible to get the number of digested samples from the soundcard, which allowed us to stay in sync with the other components. I have learned, that you need to keep track of the DTS (Decoding Time Stamp), the time when it has to be decoded, and the PTS (Presentation Time Stamp), the time where the audience receive the data (incl. the time the sound reaches your ear ;-). PTS and DTS shall be available through the diplexer, which shall receive it through the stream. Having the number of digested samples by the hardware is necessary to respond reasonable to the diplexer. No under/overflows .. and we can avoid huge buffers. IMHO .. this must exist in the current ALSA version as well. Just my 2 cents .. Cheers, Sven
Hello, On Sat, Apr 28, 2007 at 11:39:12PM +0200, Reimar D?ffinger wrote:
what do you think about attached patch? It fixes the massive desync that happens esp. when doing lots of frame stepping with -ao oss. It is a bit hackish though, and in difference to alsa it will still loose some sound during pause and not play any sound while framestepping.
Since Rich agreed on IRC that it's still better than the current situation and nobody really objected I finally applied it. Greetings, Reimar Döffinger
participants (6)
-
Attila Kinali -
Compn -
Ivan Kalvachev -
Reimar Döffinger -
Rich Felker -
Sven Gothel