Truncated start when seeking back to zero

[sezero]

Noticed this in gnome/gstreamer bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=694811

Didn't try with gstreamer, but it does happen with the wildmidi player
app, noticeable with the bug reporter provided midi from the bugzilla
entry: cleanest way to reproduce is pausing the playback, hitting '.'
until it is at 0, and unpausing.

[sezero]

PING?

[chrisisonwildcode]

Has this been tested with what is now wildcode-updates?

[sezero]

On 9/7/14, chrisisonwildcode notifications@github.com wrote:

Has this been tested with what is now wildcode-updates?

Just tested it and it is very much broken:

With the wildcode-updates branch, there is a 10 seconds of silence
at the beginning of the playback by comparison to master branch or
wildmidi-0.3 branch. If I pause, go bock to start and unpause, this
time it has 20 seconds of silence. However, possibly because of the
extra silence, there is no truncation which is the original bug is
about.

Whatever the fix will be, please e document it to me so that I can
backport it to wildmidi-0.3 too.

[sezero]

PING?

[chrisisonwildcode]

Been looking into this, I can't seem to replicate it on the -updates branch ... please verify that this still exists and that I didn't ninja fix this.

[psi29a]

@sezero ping? :)

What are the steps to duplicate this?

[sezero]

@sezero ping? :)

Nothing is fixed for me in wildcode-updates branch.

What are the steps to duplicate this?

I already outlined them in this thread but here it is again:

• Download the midi file from the original gstreamer bug:
  https://bugzilla.gnome.org/attachment.cgi?id=237557
  (bug page: https://bugzilla.gnome.org/show_bug.cgi?id=694811)
  I renamed it to pix.mid
• Compile wildmidi either from the master branch or 0.3 branch which
  results in one experience, or compile from wildcode-updates branch
  which results in a somewhat different experience.
• Play the midi: ./wildmidi -c /your/timidity.cfg /path/to/pix.mid
  and see that you hear the music. Allow it to play a little, say 10s,
  and then press 'p' to pause. Press ',' until you rewind to 0. Then
  re-press 'p' to resume playing.
• With master branch or 0.3 branch, I reproduce the original bug
  report from gstreamer / gnome bugzilla. The music starts immediately.
• with wildcode updates branch: The music does NOT start immediately:
  there is about 10s of silence at start. Upon performing the pause,
  rewind to 0 and resume sequence I described above, the silence at the
  start now becomes 20 or 21 seconds

[psi29a]

Back to the drawing board! Sorry about that, I thought perhaps I needed gstreamer to test, but we have the issue in our player as well. Is there any difference in the dumped midi file with the input file?

[chrisisonwildcode]

I'm looking into this today ... it "shouldn't" be happening and if you reward without pausing then you don't get the issue, will need to look at how pause is handled.

[chrisisonwildcode]

Ok, I'm calling not it!

Someone re-wrote (from how I originally had it) how pause is handled in the player ...

Pause for different drivers ...

WAV:
pause_output = pause_output_nop;
resume_output = resume_output_nop;

Windows:
pause_output = pause_output_nop;
resume_output = resume_output_nop;

SoundBlaster:
if (sb.caps & SBMODE_16BITS) { /* can do stereo, too */
send_output = write_sb_s16stereo;
pause_output = sb_silence_s16;
resume_output = resume_output_nop;
printf("Sound Blaster 16 or compatible (16 bit, stereo, %u Hz)\n", rate);
} else if (sb.caps & SBMODE_STEREO) {
send_output = write_sb_u8stereo;
pause_output = sb_silence_u8;
resume_output = resume_output_nop;
printf("Sound Blaster Pro or compatible (8 bit, stereo, %u Hz)\n", rate);
} else {
send_output = write_sb_u8mono;
pause_output = sb_silence_u8;
resume_output = resume_output_nop;
printf("Sound Blaster %c or compatible (8 bit, mono, %u Hz)\n",
(sb.dspver < SBVER_20)? '1' : '2', rate);
}

ALSA:
pause_output = pause_output_nop;
resume_output = resume_output_nop;

OSS:
pause_output = pause_output_oss;
resume_output = resume_output_nop;
static void pause_output_oss(void) {
ioctl(audio_fd, SNDCTL_DSP_POST, 0);
}

OpenAL
pause_output = pause_output_openal;
resume_output = resume_output_nop;
static void pause_output_openal(void) {
alSourcePause(sourceId);
}

[chrisisonwildcode]

So who ever wrote that ^^^^ you're it for this one.

[chrisisonwildcode]

Infact if I do this (below) I don't get the added delay.

            case 'p':
                if (inpause) {
                    inpause = 0;
                    fprintf(stderr, "       \r");
                    //resume_output();
                } else {
                    inpause = 1;
                    fprintf(stderr, "Paused \r");
                    //pause_output();
                    continue;
                }
                break;

[psi29a]

Can we try older versions to verify?

It is very possible that we did this to fix issues that cropped up fixing the issues with 0.2.x

519ca32 (sezero 2014-03-01 10:27:03 +0200 315) pause_output = pause_output_nop;
94a0e8e (sezero 2014-03-15 11:15:16 +0200 316) resume_output = resume_output_nop;

[sezero]

pause_output() and resume_output() function pointers are mine. they are
necessary for some drivers where pausing may require sending a message
to the driver or library, otherwise its buffer would keep playing its
buffer during pause time for example. as you can see it is nop for most
drivers.

as I told before, the extra 10s silence is already present when I begin
playing with wildcode-updates, the added extra silence is just a bonus
from puasing rewinding and resuming.

however, with the master or 0.3 branches, there is neither a silence at
the very beginning, nor any additional silence upon pause/rewind/resume
but only the truncation which is the bug subject.

[chrisisonwildcode]

Um, there is no 10secs of silence from the start on my end except for music that has the silence in them.

Yes I get added silence when I pause and rewind with the pause calls within the player. When I comment out those pause calls then there is no added silence.

[chrisisonwildcode]

Also noticed that when you resume (after rewind/fastforward) it plays whats remaining in the driver buffer ... maybe it should clear it in these cases.

[sezero]

On 1/3/15, chrisisonwildcode notifications@github.com wrote:

Um, there is no 10secs of silence from the start on my end except for music
that has the silence in them.

which driver are you using?

[chrisisonwildcode]

AL

[sezero]

On 1/3/15, chrisisonwildcode notifications@github.com wrote:

AL

Well, it was a dumb question anyway. the silence at the very beginning
of playback cannot be related to the driver in use.
Bret: can you reproduce my silence reports at your end?

[sezero]

Can you also try with the master or 0.3 branch and see the difference?

[chrisisonwildcode]

sezero ... what driver are you using and how big a buffer does it have within wildmidi player?

[sezero]

On 1/3/15, chrisisonwildcode notifications@github.com wrote:

sezero ... what driver are you using and how big a buffer does it have
within wildmidi player?

I am using OSS. there is no driver side buffer for it, it only accepts
the 16384 bytes common buffer of the player.

Just tried with uptodate wildcode-updates branch and this time
using openal driver, I reproduced my silence experience.

FWIW, I am testing with "Release" type build, i.e. I congigure like:
cmake -DCMAKE_BUILD_TYPE="Release" -DWANT_XXXDRV=1 ...

[chrisisonwildcode]

can you throw the file you are trying to play my way please ...

[sezero]

On 1/3/15, chrisisonwildcode notifications@github.com wrote:

can you throw the file you are trying to play my way please ...

I already gave the link https://bugzilla.gnome.org/attachment.cgi?id=237557

but here it is (sent to your personal email)

[chrisisonwildcode]

Think I found ya problem ... the huge delta right at the start of the track

Start of Track
Track Size: 8107
Delta: 5376, Accumilated Delta: 5376
Set Patch: chan(9) patch(0)
Delta: 0, Accumilated Delta: 5376
Meta Event: Unsupported (4)
Meta data (5 bytes):
0x64 0x72 0x75 0x6d 0x73
Delta: 0, Accumilated Delta: 5376
Controller: chan(9) ctrl(7) set(100)
Delta: 0, Accumilated Delta: 5376
Set Patch: chan(9) patch(0)
Delta: 0, Accumilated Delta: 5376
Note On: chan(9) note(38) vel(77)

Hexediting to check file manually

[chrisisonwildcode]

yep, even manually the delta value is 0xaa 0x00 which when you do ((0xaa & 0x7f) << 7) + (0x00 & 0x7f) you get 5376

[sezero]

On 1/3/15, chrisisonwildcode notifications@github.com wrote:

yep, even manually the delta value is 0xaa 0x00 which when you do ((0xaa &
0x7f) << 7) + 0x00 you get 5376

So it's a (somehow) broken file? Then how do we not get the silence
with master or wildmidi-0.3 branches?

[chrisisonwildcode]

looking at the old wildmidi_lib.c (trunk and 0.3) it did have a bug in there related to the initial delta in tracks. wildmidi-updates midi handling was just about completely re-written so the additional formats could be added.

Also tracking the execution I found another bug ... seeing if they were fixed in wildmidi-updates ... and yes it was fixed in -updates :P

[chrisisonwildcode]

Basically, 0.3 and trunk have the initial delta tagged to the first event. However any delta tagged to an event isn't handled until after the event is executed (error on my part from way back).

In comes bug number 2, when executing events, the code switched to the next event before checking the tagged delta ... hence the initial "silence" of sezero's midi was never heard. This bug has much wider reaching consequences including incorrect timing of events. Meaning files could be played incorrectly by Trunk and 0.3

[chrisisonwildcode]

sezero ... I tell you what I'll do for you, I'll add a command line option to trim leading "silence" during playback ... after I get some sleep.

In the mean time need someone to work out how to flush the audio buffers so that they are reset/cleared when you FF or RW ... or we need to use the audio drivers differently ...

[psi29a]

Someone should update that bug/ticket to include the fact that the midi isn't valid (broken) and say why.

[chrisisonwildcode]

Update: The MIDI file that sezero was having the reported issue with has a huge delta amount at the beginning which is causing the "silence" at the start of the song. This had not occurred with previous versions of WildMIDI because of undetected bugs which have now been fixed.

[chrisisonwildcode]

Anyone mind if I close this and open a new ticket regarding audio driver buffers need to be cleared when FF'ing or RW'ing.

[psi29a]

Create the other ticket for 0.4 milestone. Leave this one open until the ticket it links against is updated and the new ticket is closed since they are related.

[chrisisonwildcode]

sezero PING! Grab latest wildcode-updates and add -s to your command line :)

[sezero]

Looks good now.

[chrisisonwildcode]

can we close this now?

[sezero]

Yes