[ glame-Bugs-544336 ] play_update_marker correction for buffer

[<no...@so...>]

Bugs item #544336, was opened at 2002-04-15 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=101627&aid=544336&group_id=1627

Category: GUI
Group: normal
Status: Open
Resolution: Wont Fix
Priority: 1
Submitted By: Likai Liu (likai)
Assigned to: Richard Guenther (richi)
Summary: play_update_marker correction for buffer

Initial Comment:
It would be nice if the play_update_marker() function
in gui/waveeditgui.c can correct for audio output
buffer size, so the visual doesn't leap "ahead" of the
actual sound when the audio buffer is large.

Currently the position that play_update_marker()
obtains from filterparam_val_pos(waveedit->pm_param)
comes from the swapfile position. Swapfile goes ahead
of the actual sound that gets played by the "audio out"
plugin for buffering. The distance of the swapfile
position and actual sound played gets large when
playback buffer size is large. I propose that when
play_update_marker obtains the playback position, it
substracts this position by buffer size, and set the
marker in the approximated location where audio is
supposed to be playing. This makes the GUI a lot more
pleasant to watch when playback.

Since I'm new to glame source code, I must admit this
proposal is not the best one. Please let me know if
there is any follow ups on this issue.

Thanks.

Likai Liu

----------------------------------------------------------------------

>Comment By: Likai Liu (likai)
Date: 2002-04-16 09:56

Message:
Logged In: YES 
user_id=325449

are you absolutely sure the waveeditgui is getting the
playback position from audio_out plugin? ;-)

as in 0.6.2's source code, the play() function says:

active_waveedit->pm_param = filterparamdb_get_param(
    filter_paramdb(swin), FILTERPARAM_LABEL_POS);

where swin is obtained by:

gpsm_grp_foreach_item(grp, item) {
    swin = net_add_gpsm_input(net, (gpsm_swfile_t *)item,
        start, end - start + 1, loop ? 1 : 0);
    if (!swin)
        goto fail;
}

Though I'm not sure, but it surely looks like it's getting
swin as the swapfile. Since the play function syncs the
display with swin's position, it doesn't account for
audio_out's buffer delay.

I've tried to reduce the buffer to 128 samples and the
visual leap/audio lag does get shorter, but in return I get
a lot of clicks because I'm not trying to fine tune for
realtime.

I'm still not sure what you mean by jitter of the sample
frequency of the plugins position. By saying jitter, you're
probably saying there is a deviation of leap ahead or behind
every so often. If we average the jitter, at least we get an
average mean position very close to true position. But if we
use the position from the wrong buffer/plugin, then there is
a systemmatic error of the playback position. This
systemmatic error grows as one increases buffer size.


----------------------------------------------------------------------

Comment By: Richard Guenther (richi)
Date: 2002-04-16 03:25

Message:
Logged In: YES 
user_id=7575

It uses the audio plugin position, if its playback and not
looping, only if looping it uses the swapfile input, if
recording it uses the swapfile output. You can't do better,
I think (apart from "guessing" the delay, as you say - but
for playback the audio_out plugin should guess and correct
the position accordingly).

Note that you always have +- jitter of the sample frequency
of the plugins position, i.e. 1/10 sec, which will always be
larger than the error from the buffersize/delay.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=101627&aid=544336&group_id=1627