Igevorse Otonnoleare

Seek from JACK Transport: video demo

22 June 2014 | 09:34 pm

Overview of work this week

In short:

  • JACK Transport reposition implemented.

If you remember, I was getting a loop between MuseScore and JACK Transport. This was due to several reasons: incomplete understanding of communicating with JACK and slightly incorrect implementation of start/stop from JACK Transport.

This week I was studying sources of applications that use JACK Transport, talking with guys from #jack and correcting my code. Actually, I had to rewrite it from scratch because I went the wrong path last week.

JACK provides 2 methods of sync: for "slow" clients and for the "fast". If application has to read something from disk (imagine 4K video) while seeking, or cannot seek immediately, it is a slow client. Otherwise, it is a fast client. I knew little about working as a fast client, and decided to use a sync callback intended for slow clients. This callback tells us current state an position of JACK Transport.

After talking in #jack (IRC) I understood that using sync callback is wrong in my case - MuseScore is "fast" client because it can seek immediately. In general, both of these approaches work, but we shouldn't use a steam-hammer to crack nuts. Each approach for it's own case.

Being a "fast" client, in a process cycle I should compare JACK Transport's position and position that I expect. If they're not equal, seek to new position. After implementing it I've got a loop problem again, because I wrote new implementation not because of loop problem, but because I should use a right approach.

Implementation of start/stop from JACK Transport was slightly incorrect. It worked well before I began implementing seek feature, but now it makes some difficulties. To be clear: one unnecessary function call can cause several calls. Called functions call several functions again (and the initial too). So, we're getting a loop with increasing amount of function calls every second. I used "lazy" way to fix it - we shouldn't do something if we really don't need to do it. So, I reduced amount of calls for starting, stopping and seeking to JACK Transport and now it works well.

In previous post I described 4 basic cases of using JACK Transport:

  1. Internal seek before playing - clicking on notes and then pressing "play" in MuseScore.
  2. Internal seek while playing - pressing "play" in MuseScore and then clicking on notes.
  3. External seek before playing - seeking via JACK Transport and then pressing "play".
  4. External seek while playing - pressing "play" and seeking via JACK Transport.

You can see the video that shows these cases below (click here to watch on youtube).

I prerecorded video of playing an example score in MuseScore and opened it in qjadeo (GUI front-end to xjadeo). You can see this window on the right of the screen. MuseScore would be in sync with xjadeo.

For seeking from JACK Transport I use Catia and gjacktransport.

Sorry for the little async of audio and video - I had some problems with recording (does anybody know how to record perfectly synced video from x11grab and JACK?).

00:00 - seek from MuseScore while not playing

00:28 - seek from MuseScore while playing

00:41 - seek from Catia while not playing

01:04 - seek from Catia while playing

01:22 - seek from gJackTransport while playing

Key tasks that stalled

None. On the contrary, I moved forward and deepened my knowledge.

Upcoming tasks this week

Basic seeking is implemented now, but there are still some bugs that I need to fix. Seeking does not work correct with repeats now. Seeking with loops works but can be done better. Note after breath sometimes doesn't play.

Also, my implementation couldn't be merged right now because it will break working with other sound-systems (ALSA, etc.). I should fix it and test again.

As usual, you can find me on IRC #musescore as igevorse.

Also feel free to write me about implementing some JACK-related features that you need and want.

« JACK Transport: first steps · Seek from JACK Transport: video demo · JACK Transport: code published »

Leave your response!

Style `onWall HashCode` by Lited & Sayori
Get your own blog immediately for free with Lited!