From: Miguel F. <mi...@ce...> - 2002-11-28 12:28:17
|
Hi Heiko, i've just checked your change on cvs log and it seems you reverted to the old behaviour (i guess it's probably safe to say that the feedback loop is more experimental than this approach! :) the clock/metronom adjusting from audio_out is meant to correct very small errors (like caused by a small drift between soundcard reference and system clock). unfortunately something must have being wrong there, because the correction code seemed way too much used. in theory the main difference between adding to scr or to vpts_offset is that the later would cause the metronom to distribute the error over several frames. if you advance the scr too much, frames will be dropped instead. in short: a lot have changed since i wrote this code. at that time i did extensive tests (including tweaking my sound card rate by a few hertz off the nominal value) and it performed quite well. so until i have time to revisit the idea, it should be probably ok to keep your changes... regards, Miguel |
From: Heiko S. <hsc...@ft...> - 2002-11-28 13:51:18
|
Hey Miguel, thanks for your thoughts, your mail was somewhat reassuring to read ;) > i've just checked your change on cvs log and it seems you reverted to > the old behaviour (i guess it's probably safe to say that the feedback > loop is more experimental than this approach! :) :) well, the most experimental part about it is probably that i've removed most of the inhibiting conditions of that if clause. and adjusting the clock by the entire value of the gap, not just a smaller fraction of it. what i will try to do is set the clock by smaller steps (so that the clock won't oscillate heavily or something like that). > the clock/metronom adjusting from audio_out is meant to correct very > small errors (like caused by a small drift between soundcard reference > and system clock). unfortunately something must have being wrong there, > because the correction code seemed way too much used. as far as i could tell, the previous implementation of this ADJ_VPTS branch in the code had no positive effects whatsoever. i specifically looked at the value of 'gap' in the audio_out logs and noticed no improvement in the gap values after ADJ_VPTS had happened (not even distributed over the next handful of frames). guenter suggested that METRONOM_ADJ_VPTS_OFFSET is actually supposed to do something entirely different, namely define a diff between audio and video. i am unsure what to think. whichever way, for my mpeg stream the ADJ_VPTS if clause seemed to have no positive effect and i always ended up in the ao_fill_gap() branch after a while. and had a skip in the audio, which of course sucks. this is why i guess that some changes (not nevessarily the ones i made) to the ADJ_VPTS part will be the solution - if the change is subtle enough then it will most likely not break anything else, and hopefully still give me smooth playback of my mpeg1 streams. i'm quite happy that no changes to the metronom seem to be necessary. > in theory the main difference between adding to scr or to vpts_offset is > that the later would cause the metronom to distribute the error over > several frames. if you advance the scr too much, frames will be dropped > instead. yes, i think that is occasionally happening right now (hard to tell) - that is why i want to make the changes to the scr smaller, i'm planning to fiddle with that in the evening. regards, Heiko |
From: Miguel F. <mi...@ce...> - 2002-11-28 14:25:13
|
hi heiko, On Thu, 2002-11-28 at 11:50, Heiko Schaefer wrote: > :) well, the most experimental part about it is probably that i've removed > most of the inhibiting conditions of that if clause. and adjusting the > clock by the entire value of the gap, not just a smaller fraction of it. right, but these inhibiting conditions were there to prevent doing several updates in a row and not realizing it. it was needed because the metronom feedback loop has a delay due the audio buffers. updating the scr directly takes effect immediately (a feedback loop with zero delay). > what i will try to do is set the clock by smaller steps (so that the clock > won't oscillate heavily or something like that). i would expect to not update the scr often with this mechanism. if we do, we are probably hiding a bug somewhere else. > > the clock/metronom adjusting from audio_out is meant to correct very > > small errors (like caused by a small drift between soundcard reference > > and system clock). unfortunately something must have being wrong there, > > because the correction code seemed way too much used. > > as far as i could tell, the previous implementation of this ADJ_VPTS > branch in the code had no positive effects whatsoever. > > i specifically looked at the value of 'gap' in the audio_out logs and > noticed no improvement in the gap values after ADJ_VPTS had happened (not > even distributed over the next handful of frames). guenter suggested that > METRONOM_ADJ_VPTS_OFFSET is actually supposed to do something entirely > different, namely define a diff between audio and video. i am unsure what > to think. no, you are mistaking it for METRONOM_AV_OFFSET. METRONOM_ADJ_VPTS_OFFSET adds some value to vpts_offset, which would create a difference against predicted values on metronom (see line 402+). as i said, i quite sure it used to work when i coded it because i did a lot of tests with bad sample rates and bad streams... > whichever way, for my mpeg stream the ADJ_VPTS if clause seemed to have no > positive effect and i always ended up in the ao_fill_gap() branch after a > while. and had a skip in the audio, which of course sucks. agreed, it's well known that audio skips are much more annoying to the user than small video jitters. > this is why i guess that some changes (not nevessarily the ones i made) to > the ADJ_VPTS part will be the solution - if the change is subtle enough > then it will most likely not break anything else, and hopefully still give > me smooth playback of my mpeg1 streams. i'm quite happy that no changes to > the metronom seem to be necessary. great! i told you that metronom heuristics were probably not needed to fix your problem! :) in some near future i believe we should have two operation modes (selectable from config) for fixing sample rate drift as James suggested: 1) adjust scr/vpts_offset/whatever to change video speed and match playing sound speed reported by sound card. 2) resample audio to keep video at the nominal rate. both of them have their beneficts, so it should be ok to let the user change the strategy if he wants. regards, Miguel |
From: Michael R. <mr...@us...> - 2002-11-28 20:31:17
|
Hi Heiko, > > the clock/metronom adjusting from audio_out is meant to correct > > very small errors (like caused by a small drift between soundcard > > reference and system clock). unfortunately something must have > > being wrong there, because the correction code seemed way too much > > used. > > as far as i could tell, the previous implementation of this ADJ_VPTS > branch in the code had no positive effects whatsoever. It had: it fixed dxr3 sync. (I'm still thanking Miguel for that.) So I fear this is broken now, since the card does not like adjusting its clock too much. But I will do some testing on this and report the results. There is one problem with the current solution, though: (Sorry for only criticising your work, Heiko, but I had no problems with the past solution, so I can only experience the bad effects. ;) Since we currently have only one global clock in xine, the current method is problematic when playing multiple streams, because adjusting the clock because of audio drift in ONE stream will affect ALL streams. We have to find something better here. (Either for audio_out or for the clocking strategy.) Michael -- Linux is for Network Mac is for Artwork Windows is for Solitaire |
From: Heiko S. <hsc...@ft...> - 2002-11-29 12:23:34
|
Hi Michael, thanks for the input, that's what i announced my change for. i was unsure what it could break, and apparently there is something. > > as far as i could tell, the previous implementation of this ADJ_VPTS > > branch in the code had no positive effects whatsoever. > > It had: it fixed dxr3 sync. (I'm still thanking Miguel for that.) So I > fear this is broken now, since the card does not like adjusting its > clock too much. But I will do some testing on this and report the > results. ok, that does it. i think it really makes sense (like miguel has suggested earlier) to give xine two behaviours for the user to choose from (via a config-setting): 1) the system clock is the master (i.e. no fiddling with the clock) - this was the behavious before my commit. that seems to be good for dxr3 users and generally for people who want absolutely smooth video playback at the price of possible audio glitches. 2) the audio clock is the master - that should be good for people who like the audio to be uninterrupted, no matter what. if the streams ptses are bad, then video playback will subordinate to the audio clock (i.e. video will be speeded up or slowed down a bit) ... or something similar. > There is one problem with the current solution, though: (Sorry for only > criticising your work, Heiko, but I had no problems with the past > solution, so I can only experience the bad effects. ;) oh, please criticise :) > Since we currently have only one global clock in xine, the current > method is problematic when playing multiple streams, because adjusting > the clock because of audio drift in ONE stream will affect ALL streams. i really do not understand that. i realize that there have been changes to allow for something called multiple streams, but i don't understand what the means. i was under the impression that this can be used for external subtitles and the likes. is that right ? > We have to find something better here. (Either for audio_out or for the > clocking strategy.) that's fine with me :) as long as my mpeg1 streams with slightly odd pts values will play back smoothly (without other stuff being broken, of course), i am happy ;) i'm looking forward to thoughts and suggestions. cheers, Heiko |
From: Miguel F. <mi...@ce...> - 2002-11-29 12:54:11
|
Hi Heiko, On Fri, 2002-11-29 at 10:23, Heiko Schaefer wrote: > i think it really makes sense (like miguel has suggested earlier) to give > xine two behaviours for the user to choose from (via a config-setting): > > 1) the system clock is the master (i.e. no fiddling with the clock) - this > was the behavious before my commit. > that seems to be good for dxr3 users and generally for people who > want absolutely smooth video playback at the price of possible audio > glitches. > 2) the audio clock is the master - that should be good for people who like > the audio to be uninterrupted, no matter what. if the streams ptses are > bad, then video playback will subordinate to the audio clock (i.e. > video will be speeded up or slowed down a bit) > > ... or something similar. That's not really what i've suggested... people NEVER like the audio to be interrupted, this simply can't happen because it's annoying to the listener. What i said is that we need to adjust *either* the audio (resample) or the video (framerate) to keep a good playback. Both your patch and the previous code are the later kind of behaviour, they just differ on implementation details. regards, Miguel |
From: Heiko S. <hsc...@ft...> - 2002-11-29 14:59:26
|
Hi Miguel, everyone, > > 1) the system clock is the master (i.e. no fiddling with the clock) - this > > was the behavious before my commit. > > that seems to be good for dxr3 users and generally for people who > > want absolutely smooth video playback at the price of possible audio > > glitches. > > 2) the audio clock is the master - that should be good for people who like > > the audio to be uninterrupted, no matter what. if the streams ptses are > > bad, then video playback will subordinate to the audio clock (i.e. > > video will be speeded up or slowed down a bit) > > > > ... or something similar. > > That's not really what i've suggested... people NEVER like the audio to > be interrupted, this simply can't happen because it's annoying to the > listener. ok, sorry for misquoting you. > What i said is that we need to adjust *either* the audio (resample) or > the video (framerate) to keep a good playback. uhm - wouldn't resample lead to a change of pitch ? i think at least in some cases that is even less acceptable than interruption in audio... (concert videos, music, ...) and ac3/dts audio (with passthrough) can't really be resampled, i guess. > Both your patch and the previous code are the later kind of behaviour, > they just differ on implementation details. hmm... i believe the previous code always honored the system clock (at least for my way of using xine) - in the case of my weird mpeg streams that lead to jumps in the audio, since audio_out decided to fill gaps with 0-buffers. but i might be wrong - that's just my interpretation of the logs. regards, Heiko |
From: Miguel F. <mi...@ce...> - 2002-11-29 17:42:36
|
Hi Heiko, On Fri, 2002-11-29 at 12:58, Heiko Schaefer wrote: > > That's not really what i've suggested... people NEVER like the audio to > > be interrupted, this simply can't happen because it's annoying to the > > listener. > > ok, sorry for misquoting you. > > > What i said is that we need to adjust *either* the audio (resample) or > > the video (framerate) to keep a good playback. > > uhm - wouldn't resample lead to a change of pitch ? > i think at least in some cases that is even less acceptable than > interruption in audio... (concert videos, music, ...) right, but the mechanism is intended to be used to fix very small drift errors... anyway, for most material if you change pitch by, lets say, 0.1 to 0.5% it won't be much noticed by the user (specially if they never heard the original... but i'm not saying i want to do that!!). :) > and ac3/dts audio (with passthrough) can't really be resampled, i guess. probably not. that's why the mechanism must be user selectable... > > Both your patch and the previous code are the later kind of behaviour, > > they just differ on implementation details. > > hmm... i believe the previous code always honored the system clock (at > least for my way of using xine) - in the case of my weird mpeg streams > that lead to jumps in the audio, since audio_out decided to fill gaps with > 0-buffers. > > but i might be wrong - that's just my interpretation of the logs. it's most likely that previous code contained errors. Or, you were trying to use it to fix a drift as bad as 1% to 2%: it was never designed to fix that and, in fact, it does not. that is, suppose your stream specified a sample rate of 44100hz but the pts values were increasing slower that it should by 2%. the feedback would try to fix the error but the correction would not be enough, then you acummulate it and have gaps from time to time. looks like a good explanation, isn't it?? ;) regards, Miguel |
From: Arpi <ar...@th...> - 2002-11-29 21:08:23
|
Hi, > > > What i said is that we need to adjust *either* the audio (resample) or > > > the video (framerate) to keep a good playback. > > > > uhm - wouldn't resample lead to a change of pitch ? > > i think at least in some cases that is even less acceptable than > > interruption in audio... (concert videos, music, ...) > > > right, but the mechanism is intended to be used to fix very small drift > errors... anyway, for most material if you change pitch by, lets say, > 0.1 to 0.5% it won't be much noticed by the user (specially if they > never heard the original... but i'm not saying i want to do that!!). :) And how did you imagine implementing the audio resampler? Nearest neighbour or linear interpolation just sucks in quality. Using poliphase filters are ok, but it needs coeffs & big table generation which takes long, too long for runtime changing conversion ratio. > that is, suppose your stream specified a sample rate of 44100hz but the > pts values were increasing slower that it should by 2%. the feedback > would try to fix the error but the correction would not be enough, then > you acummulate it and have gaps from time to time. looks like a good > explanation, isn't it?? ;) this is what -mc option does in mplayer, it sets desync tolerance :) (in seconds/frame) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: James Courtier-D. <Ja...@su...> - 2002-11-30 04:16:40
|
Miguel Freitas wrote: > > > >>and ac3/dts audio (with passthrough) can't really be resampled, i guess. >> >> > >probably not. that's why the mechanism must be user selectable... > > > > > ac3/dts in passthru mode is never resampled, instead, a few extra and fewer padding samples are removed. E.g. dts pack might be 1024 samples long, but cover 1536 samples of audio sound, so we pad the dts pack to 1536 with zeros. So, if we need to add or remove a sample, we just add or remove one of the pad samples. Thus we correct the output, without effecting the passthru sound at all. Cheers James |
From: James Courtier-D. <Ja...@su...> - 2002-11-30 04:09:05
|
Heiko Schaefer wrote: > > >>What i said is that we need to adjust *either* the audio (resample) or >>the video (framerate) to keep a good playback. >> >> > >uhm - wouldn't resample lead to a change of pitch ? >i think at least in some cases that is even less acceptable than >interruption in audio... (concert videos, music, ...) > >and ac3/dts audio (with passthrough) can't really be resampled, i guess. > > >regards, > >Heiko > > Here is a quick description of what I mean by the "resampling" method. We have the unix system clock (sc) and the audio hardware clock (hc). The sc is always more accurate than the hc. So the aim is to somehow correct the hc so that it matches the sc. When one sends samples to the audio hardware, it plays them out using the hc. Here is an example: - Start both sc and hc clock together. sc hc 0 0 1 1 2 2 (some period of time) 33 34 34 35 35 36 So, after some period of time, the xine audio_out loop will gradually get a "diff" value that increases, until finally xine trys some sort of correction, drops samples, clock feedback corrections etc. The way to correct these slowly diverging clocks is to somehow insert of remove a single extra sample. E.g sc counts 90000 samples time. hc counts 89999 sample time, over this period, we need to resample the samples so that although the sc counts 90000 samples, we only output 89999 samples. So, in this way, the ear cannot tell the difference, but the sound coming out of the speakers is now in sync with the sc and not the hc. The advantage of this method is that video output will then stay accurate, and the audio hardware is just forced to comply without any audible side-effects. This method will help considerably if someone is using TV out, that cannot change the video frame duration at all. I thought of this method some time ago, and I even emailed a patch to the xine-devel list demonstrating it. From a conceptual point of view, I never liked the idea of the Global System clock in xine-lib beign adjusted at all during play. Now, with multiple streams all using the same global system clock, the current feedback method is doomed to failure. So, in summary, the resampling method is only used for very small "diff" values, otherwise the listener will notice big changes in audio frequency. Cheers James |
From: Miguel F. <mi...@ce...> - 2002-11-30 09:57:58
|
Hi James, On Sat, 2002-11-30 at 02:10, James Courtier-Dutton wrote: > The way to correct these slowly diverging clocks is to somehow insert of > remove a single extra sample. > E.g > sc counts 90000 samples time. > hc counts 89999 sample time, > over this period, we need to resample the samples so that although the > sc counts 90000 samples, we only output 89999 samples. A minor comment: although it looks great in theory you must realize that not all audio drivers have such arbitrary good timming report. So you can't really count on being able to add/remove a single sample. If you implement it naively it is most likely to cause a lot of audio distortion in order to keep the sync. regards, Miguel |
From: Miguel F. <mi...@ce...> - 2002-11-30 22:21:24
|
Ok folks, i've commited some fixes to metronom and audio_out... the feedback loop is back and we don't play with the master clock anymore. for more information check the cvslog. i believe this must be the best xine metronom ever: no ugly hacks, weird heuristics, just plain simple pts->vpts mapping and drift corrections. so please try to beat it and report bugs... no, no, not yet! i'm supposed to be studying this weekend! :) regards, Miguel |
From: James Courtier-D. <Ja...@su...> - 2002-12-01 11:47:08
|
Miguel Freitas wrote: >Hi James, > >On Sat, 2002-11-30 at 02:10, James Courtier-Dutton wrote: > > >>The way to correct these slowly diverging clocks is to somehow insert of >>remove a single extra sample. >>E.g >>sc counts 90000 samples time. >>hc counts 89999 sample time, >>over this period, we need to resample the samples so that although the >>sc counts 90000 samples, we only output 89999 samples. >> >> > > >A minor comment: although it looks great in theory you must realize that >not all audio drivers have such arbitrary good timming report. So you >can't really count on being able to add/remove a single sample. If you >implement it naively it is most likely to cause a lot of audio >distortion in order to keep the sync. > > >regards, > >Miguel > > > > I thought of that already. which is why I agree that the user should be able to choose which method to use. feedback or resampling. With "feedback" working on most systems, and "resampling" working on a lot of systems, we should leave both methods in there and let the user choose. :-) Cheers James |
From: <bar...@t-...> - 2002-12-02 23:55:19
|
hi james, On 12/01, James Courtier-Dutton wrote: > >A minor comment: although it looks great in theory you must realize that > >not all audio drivers have such arbitrary good timming report. So you > >can't really count on being able to add/remove a single sample. If you > >implement it naively it is most likely to cause a lot of audio > >distortion in order to keep the sync. > I thought of that already. which is why I agree that the user should be > able to choose which method to use. > feedback or resampling. > With "feedback" working on most systems, and "resampling" working on a > lot of systems, we should leave both methods in there and let the user > choose. :-) i've learned that from a user's standpoint it is not the best thing to do to place such technical detail decisions on the end-users shoulder. assigning a high expert level to these pseudo-options might be a workaround, but the solution is definitely that such things should just work correclty out of the box. cheers, guenter > > Cheers > James > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel -- -- flowchart, n. & v.: [From flow "to ripple down in rich profusion, as hair" + chart "a cryptic hidden-treasure map designed to mislead the uninitiated."] 1. n. The solution, if any, to a class of Mascheroni construction problems in which given algorithms require geometrical representation using only the 35 basic ideograms of the ANSI template. 2. n. Neronic doodling while the system burns. 3. n. A low-cost substitute for wallpaper. 4. n. The innumerate misleading the illiterate. "A thousand pictures is worth ten lines of code." -- The Programmer's Little Red Vade Mecum, Mao Tse T'umps. 5. v.intrans. To produce flowcharts with no particular object in mind. 6. v.trans. To obfuscate (a problem) with esoteric cartoons. -- Stan Kelly-Bootle, "The Devil's DP Dictionary" |
From: Arpi <ar...@th...> - 2002-11-29 14:44:36
|
Hi, > 1) the system clock is the master (i.e. no fiddling with the clock) - this > was the behavious before my commit. > that seems to be good for dxr3 users and generally for people who > want absolutely smooth video playback at the price of possible audio > glitches. this is also required for people with buggy/broken audio drivers (ie when the audio driver reports bad buffering status / delay value (GETODELAY ioctl of OSS) - it's more common than we can hope :( (no way to do audio clock syncronized smooth playback using such drivers.) > 2) the audio clock is the master - that should be good for people who like > the audio to be uninterrupted, no matter what. if the streams ptses are > bad, then video playback will subordinate to the audio clock (i.e. > video will be speeded up or slowed down a bit) this is the default method in mplayer too btw since a while in mplayer you can give a parameter -autosync, it mixes the behaviour of 1. and 2., by interpolating the audio & sys timers. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: <bar...@t-...> - 2002-11-29 15:41:43
|
hi arpi, > > 1) the system clock is the master (i.e. no fiddling with the clock) - this > > was the behavious before my commit. > > that seems to be good for dxr3 users and generally for people who > > want absolutely smooth video playback at the price of possible audio > > glitches. > this is also required for people with buggy/broken audio drivers (ie when > the audio driver reports bad buffering status / delay value (GETODELAY ioctl > of OSS) - it's more common than we can hope :( > (no way to do audio clock syncronized smooth playback using such drivers.) using GETOPTR works on some of those drivers - for everyone else xine has a softsync method cheers, guenter -- Never call a man a fool. Borrow from him. |
From: Miguel F. <mi...@ce...> - 2002-11-29 17:48:40
|
Hi Arpi, On Fri, 2002-11-29 at 13:14, Arpi wrote: > Hi, > > > 1) the system clock is the master (i.e. no fiddling with the clock) - this > > was the behavious before my commit. > > that seems to be good for dxr3 users and generally for people who > > want absolutely smooth video playback at the price of possible audio > > glitches. > this is also required for people with buggy/broken audio drivers (ie when > the audio driver reports bad buffering status / delay value (GETODELAY ioctl > of OSS) - it's more common than we can hope :( > (no way to do audio clock syncronized smooth playback using such drivers.) Yes there is... at least in xine we have two modes that can be used in such case, and one of them should give you almost perfect sync: by probing sound card buffer size to estimate the latency and keeping audio_out loop most of the time blocked by the write(). > > 2) the audio clock is the master - that should be good for people who like > > the audio to be uninterrupted, no matter what. if the streams ptses are > > bad, then video playback will subordinate to the audio clock (i.e. > > video will be speeded up or slowed down a bit) > this is the default method in mplayer too i think i noticed that already! :) at least in some older versions of mplayer the resampling were not automatic, so playing videos in a 48Khz-only had quite funny results!! ;) > btw since a while in mplayer you can give a parameter -autosync, it mixes > the behaviour of 1. and 2., by interpolating the audio & sys timers. interesting, thanks for the note. regards, Miguel |
From: Arpi <ar...@th...> - 2002-11-29 21:01:12
|
Hi, > > > 1) the system clock is the master (i.e. no fiddling with the clock) - this > > > was the behavious before my commit. > > > that seems to be good for dxr3 users and generally for people who > > > want absolutely smooth video playback at the price of possible audio > > > glitches. > > this is also required for people with buggy/broken audio drivers (ie when > > the audio driver reports bad buffering status / delay value (GETODELAY ioctl > > of OSS) - it's more common than we can hope :( > > (no way to do audio clock syncronized smooth playback using such drivers.) > > > Yes there is... at least in xine we have two modes that can be used in > such case, and one of them should give you almost perfect sync: by > probing sound card buffer size to estimate the latency and keeping > audio_out loop most of the time blocked by the write(). Yes, I did it in early (pre-0.18?) mplayer versions too, but select() was also problematic (buggy) with those broken OSS drivers. (there was even a driver which Oops'ed kernel when i used select() on it :)) With threads it can be done without select(), having a thread which keeps blocked by write(), I assume you do it this way. Estimating/measuring buffer size/latency is another nice problem :) > > > 2) the audio clock is the master - that should be good for people who like > > > the audio to be uninterrupted, no matter what. if the streams ptses are > > > bad, then video playback will subordinate to the audio clock (i.e. > > > video will be speeded up or slowed down a bit) > > this is the default method in mplayer too > > i think i noticed that already! :) > > at least in some older versions of mplayer the resampling were not > automatic, so playing videos in a 48Khz-only had quite funny results!! > ;) Yes, it was a feature :) At least the SB16 owners liked it, as the card could do 46.8khz, so playback of 48khz movies went smoothly without needing any resampling. Now it's dropped and libaf kicks in if the card cannot accept the wanted samplerate... A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu |
From: Michael R. <mr...@us...> - 2002-11-29 17:21:41
|
Hi Heiko, > thanks for the input, that's what i announced my change for. > i was unsure what it could break, and apparently there is something. > > > > as far as i could tell, the previous implementation of this > > > ADJ_VPTS branch in the code had no positive effects whatsoever. > > > > It had: it fixed dxr3 sync. (I'm still thanking Miguel for that.) > > So I fear this is broken now, since the card does not like > > adjusting its clock too much. But I will do some testing on this > > and report the results. > > ok, that does it. I will watch a DVD this evening and do some stress testing with the dxr3's sync. I will tell you tomorrow, how your code exactly behaves. > > Since we currently have only one global clock in xine, the current > > method is problematic when playing multiple streams, because > > adjusting the clock because of audio drift in ONE stream will > > affect ALL streams. > > i really do not understand that. i realize that there have been > changes to allow for something called multiple streams, but i don't > understand what the means. i was under the impression that this can > be used for external subtitles and the likes. is that right ? It can (will be possible to) be used for that, but it is more general. Currently, you can open any number of output drivers, open any number of streams, attaching the outputs to the streams and then play a different MRL on each stream. These can be totally independent files. The current limitation is: there is only one global clock. So if one audio out loop feels that there is a sync offset and adjusts this global clock, all currently playing streams will experience this jump in the clock's time. Fortunately there is currently no frontend that really makes use of this multistream features, but hopefully this situation won't last. So I think a config entry allowing to switch behaviours might be a good idea for now. Any frontend needing to and any plugin having problems with the new strategy (possibly the dxr3 - needs testing) can then switch back to the old behaviour, which did not affect the clock. Michael -- printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n"); 2.2.16 /usr/src/linux/fs/isofs/inode.c |
From: Miguel F. <mi...@ce...> - 2002-11-30 10:44:54
|
On Thu, 2002-11-28 at 18:30, Michael Roitzsch wrote: > Since we currently have only one global clock in xine, the current > method is problematic when playing multiple streams, because adjusting > the clock because of audio drift in ONE stream will affect ALL streams. > We have to find something better here. (Either for audio_out or for the > clocking strategy.) Michael, please let Heiko's changes for now. with this example i think i realized a wrong assumption i've made in the previous code, so give me a few days and i hope to fix it... i just can't rush to do it now, that would not be good for my exams! :) regards, Miguel |
From: Michael R. <mr...@us...> - 2002-11-30 15:13:52
|
Hi Miguel, > > Since we currently have only one global clock in xine, the current > > method is problematic when playing multiple streams, because > > adjusting the clock because of audio drift in ONE stream will > > affect ALL streams. We have to find something better here. (Either > > for audio_out or for the clocking strategy.) > > Michael, please let Heiko's changes for now. with this example i > think i realized a wrong assumption i've made in the previous code, > so give me a few days and i hope to fix it... i just can't rush to do > it now, that would not be good for my exams! :) No problem. In a first test yestarday evening, even the dxr3 sync seemed fine with the new code. Michael -- panic("Oh boy, that early out of memory?"); 2.2.16 /usr/src/linux/arch/mips/mm/init.c |