Cue doesn't sound for a note/lyric if the playback begins from that note's/lyric's position

[GoogleCodeExporter]

If the seek bar is placed at a note/lyric on a beat line (Pg Up/Dn) or at a
note/lyric anywhere else (Shift+Pg Up/Dn), and any cue
(metronome/clap/tone) is active.  The starting note/lyric does not sound a
cue when playback begins.  Some of the recent logic must have changed this,
as the cues sounded under these circumstances in 1.63b6.

Original issue reported on code.google.com by raynebc on 15 May 2010 at 12:30

[GoogleCodeExporter]

I think the issue may be that the AV delay is used to calculate where to seek 
when 
seeking to notes/beats. The player uses the buffer size to calculate where to 
seek 
when beginning playback. If the AV delay is longer than what is calculated to 
be the 
actual rewind time, these seek operations will actually seek the audio to 
slightly 
after the location of the position line. Could you try decreasing the AV delay 
and 
see if you can reduce it such that the audio cues play correctly?

I don't know if there is a way to get everything to work flawlessly. If I use 
the 
calculated delay as opposed to the user-set delay for seek operations, the 
position 
line won't be where you expect when you seek to a note/beat. I can't remove the 
AV 
delay setting because it is necessary to be able to account for any extra delay 
beyond the bare audio latency. Some sound drivers may add extra latency beyond 
what 
I calculate from the buffer size. Some displays may introduce extra delay as 
well.

If the AV delay is the issue maybe we could use actual positions for seek 
operations 
and only draw the position line offset by AV delay during audio playback.

Original comment by xander4j...@yahoo.com on 15 May 2010 at 4:19

[GoogleCodeExporter]

Even when I changed the AV delay to make the seek bar to appear a long ways 
before
the note I was seeked at, it did not play the note.

Original comment by raynebc on 15 May 2010 at 5:31

[GoogleCodeExporter]

You should try decreasing the AV delay. Increasing it will make the playback 
start 
further ahead.

When seeking to a note, the seek position is actually set to 'note->pos + 
eof_av_delay'. Under the current player logic, if the AV delay is set higher 
than the 
base audio latency ( ((eof_buffer_size * 2) * 1000) / audio_sample_rate ) 
playback 
will start after the position of the note and the cue will not be played.

Original comment by xander4j...@yahoo.com on 15 May 2010 at 6:07

[GoogleCodeExporter]

I changed my AV delay from 300 to 275 and it does seem quite a bit better.  
It's just
odd because it's not something I had run into before, even with the same buffer 
size
and AV delay in the previous versions of EOF.

Original comment by raynebc on 15 May 2010 at 7:37

[GoogleCodeExporter]

Just to clarify, I switched from using the AV delay to calculate the position 
in the 
audio the player starts to using the calculated buffer size. That is why it 
quit 
working for you.

Original comment by xander4j...@yahoo.com on 15 May 2010 at 12:35

[GoogleCodeExporter]

Thanks for the clarification.

Original comment by raynebc on 15 May 2010 at 5:58

[GoogleCodeExporter]

I'll consider this resolved.

Original comment by raynebc on 15 May 2010 at 9:21

• Changed state: Fixed