Re: [tim-janik/beast] Jack driver (#31)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] Jack driver (#31)

Gnome - Beast mailing list

I've rebased and squashed the PR and then fixed a couple build issues so it actually compiles and works for me (btw namespaces must be labeled with comments in Beast, I had a hard time figuring the beginnins and ends of the anon namespaces). The howto should mention that users also need to install pavucontrol, jackd2 and for building libjack-jackd2-dev. I guess the AppImage needs some extra logic to figure libjack.so is present or not.
The results can be found in this branch: wip/squashed-jack-driver


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@tim-janik in #31: I've rebased and squashed the PR and then fixed a couple build issues so it actually compiles and works for me (btw namespaces must be labeled with comments in Beast, I had a hard time figuring the beginnins and ends of the anon namespaces). The howto should mention that users also need to install pavucontrol, jackd2 and for building libjack-jackd2-dev. I guess the AppImage needs some extra logic to figure libjack.so is present or not.\r\nThe results can be found in this branch: wip/squashed-jack-driver"}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/31#issuecomment-425138551"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/31#issuecomment-425138551", "url": "https://github.com/tim-janik/beast/pull/31#issuecomment-425138551", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } }, { "@type": "MessageCard", "@context": "http://schema.org/extensions", "hideOriginalBody": "false", "originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB", "title": "Re: [tim-janik/beast] Jack driver (#31)", "sections": [ { "text": "", "activityTitle": "**Tim Janik**", "activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png", "activitySubtitle": "@tim-janik", "facts": [ ] } ], "potentialAction": [ { "name": "Add a comment", "@type": "ActionCard", "inputs": [ { "isMultiLine": true, "@type": "TextInput", "id": "IssueComment", "isRequired": false } ], "actions": [ { "name": "Comment", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"tim-janik/beast\",\n\"issueId\": 31,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}" } ] }, { "name": "Close pull request", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"PullRequestClose\",\n\"repositoryFullName\": \"tim-janik/beast\",\n\"pullRequestId\": 31\n}" }, { "targets": [ { "os": "default", "uri": "https://github.com/tim-janik/beast/pull/31#issuecomment-425138551" } ], "@type": "OpenUri", "name": "View on GitHub" }, { "name": "Unsubscribe", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 300182398\n}" } ], "themeColor": "26292E" } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: [tim-janik/beast] Jack driver (#31)

Gnome - Beast mailing list

Since you made this a new branch, I'll just add information here instead of committing to my branch.

The howto should mention that users also need to install pavucontrol, jackd2 and for building libjack-jackd2-dev.

Yes. Either this or the corresponding jack1 packages: jackd1 libjack-dev

In any case I mentioned tentative TODO items for the jack driver during our last phone call, here is a description that can be put as comment into the driver.

The jack driver as provided here should be usable. However, there are a few
things that could be improved, here is a short list.

Audio Engine start/stop
-----------------------
Currently the JACK driver registers a new BEAST client every time the device
is opened. This is problematic because connections between the BEAST jack
client and other applications will be disconnected on every close. So
redirecting output song playback through some other application would have
to be reconnected the next time the song plays. Also connecting BEAST to
other JACK clients while the device is closed - before actual playback -
would be impossible.

To fix this, there should be an explicit audio engine start/stop in BEAST.
Once the audio engine is started, the JACK client should remain registered
with JACK, even if no song is playing. This should fix the problems this
driver has due to JACK disconnect on device close.

JACK Midi
---------
Apart from audio, JACK can provide midi events to clients. Note that this
should be optional, and receiving midi events from ALSA should also be
supported.

To receive events from JACK, during setup/open BEAST should register a midi
port at the same place the audio port is registered, so that the BEAST client
will receive both, audio and midi events in the same jack callback.

This breaks with the existing API that audio driver and midi driver should be
implemented seperately, because this requires some data to be shared between
JACK audio / JACK midi driver.

Less buffering, better latency
------------------------------
Currently, the JACK driver has a ring buffer that holds some audio data.  This
introduces latency. This is not what JACK applications typically do.  So here
are some thoughts of how to avoid buffering completely.

To do so, we make the JACK callback block until BEAST has processed the audio
data.

(1) [JACK Thread] jack_process_callback gets called with N input samples
(2) [JACK Thread] wake up engine thread
(3) [JACK Thread] wait for engine thread
(4) [ENGINE Thread] engine thread processes N samples input -> N samples output
(5) [ENGINE Thread] engine thread wakes up jack thread
(6) [JACK Thread] jack_process_callback returns, supplying N output samples

So the idea is to receive input samples from jack (1) and then stall the jack
thread (2). The engine processes the samples (4) and wakes up the jack thread
(5) which then returns (6) the samples the engine created. The engine thread
can use helper threads to complete the job.

Note that this optimization works best (no buffering/latency) if the engine
block size and the jack block size are equal. It also works well if the jack
block size is an integer multiple fo the engine block size.

This avoids latency and buffering. However this may pose stricter RT
requirements onto BEAST. So whether it runs as dropout-free as the current
version would remain to be seen. A not so realtime version would buffer
M complete blocks of N samples, still avoiding partially filled buffers.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tim-janik/beast","title":"tim-janik/beast","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tim-janik/beast"}},"updates":{"snippets":[{"icon":"PERSON","message":"@swesterfeld in #31: Since you made this a new branch, I'll just add information here instead of committing to my branch.\r\n\r\n\u003e The howto should mention that users also need to install pavucontrol, jackd2 and for building libjack-jackd2-dev.\r\n\r\nYes. Either this or the corresponding jack1 packages: jackd1 libjack-dev\r\n\r\nIn any case I mentioned tentative TODO items for the jack driver during our last phone call, here is a description that can be put as comment into the driver.\r\n\r\n```\r\nThe jack driver as provided here should be usable. However, there are a few\r\nthings that could be improved, here is a short list.\r\n\r\nAudio Engine start/stop\r\n-----------------------\r\nCurrently the JACK driver registers a new BEAST client every time the device\r\nis opened. This is problematic because connections between the BEAST jack\r\nclient and other applications will be disconnected on every close. So\r\nredirecting output song playback through some other application would have\r\nto be reconnected the next time the song plays. Also connecting BEAST to\r\nother JACK clients while the device is closed - before actual playback -\r\nwould be impossible.\r\n\r\nTo fix this, there should be an explicit audio engine start/stop in BEAST.\r\nOnce the audio engine is started, the JACK client should remain registered\r\nwith JACK, even if no song is playing. This should fix the problems this\r\ndriver has due to JACK disconnect on device close.\r\n\r\nJACK Midi\r\n---------\r\nApart from audio, JACK can provide midi events to clients. Note that this\r\nshould be optional, and receiving midi events from ALSA should also be\r\nsupported.\r\n\r\nTo receive events from JACK, during setup/open BEAST should register a midi\r\nport at the same place the audio port is registered, so that the BEAST client\r\nwill receive both, audio and midi events in the same jack callback.\r\n\r\nThis breaks with the existing API that audio driver and midi driver should be\r\nimplemented seperately, because this requires some data to be shared between\r\nJACK audio / JACK midi driver.\r\n\r\nLess buffering, better latency\r\n------------------------------\r\nCurrently, the JACK driver has a ring buffer that holds some audio data. This\r\nintroduces latency. This is not what JACK applications typically do. So here\r\nare some thoughts of how to avoid buffering completely.\r\n\r\nTo do so, we make the JACK callback block until BEAST has processed the audio\r\ndata.\r\n\r\n(1) [JACK Thread] jack_process_callback gets called with N input samples\r\n(2) [JACK Thread] wake up engine thread\r\n(3) [JACK Thread] wait for engine thread\r\n(4) [ENGINE Thread] engine thread processes N samples input -\u003e N samples output\r\n(5) [ENGINE Thread] engine thread wakes up jack thread\r\n(6) [JACK Thread] jack_process_callback returns, supplying N output samples\r\n\r\nSo the idea is to receive input samples from jack (1) and then stall the jack\r\nthread (2). The engine processes the samples (4) and wakes up the jack thread\r\n(5) which then returns (6) the samples the engine created. The engine thread\r\ncan use helper threads to complete the job.\r\n\r\nNote that this optimization works best (no buffering/latency) if the engine\r\nblock size and the jack block size are equal. It also works well if the jack\r\nblock size is an integer multiple fo the engine block size.\r\n\r\nThis avoids latency and buffering. However this may pose stricter RT\r\nrequirements onto BEAST. So whether it runs as dropout-free as the current\r\nversion would remain to be seen. A not so realtime version would buffer\r\nM complete blocks of N samples, still avoiding partially filled buffers.\r\n```"}],"action":{"name":"View Pull Request","url":"https://github.com/tim-janik/beast/pull/31#issuecomment-426346015"}}}</script> <script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/tim-janik/beast/pull/31#issuecomment-426346015", "url": "https://github.com/tim-janik/beast/pull/31#issuecomment-426346015", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } }, { "@type": "MessageCard", "@context": "http://schema.org/extensions", "hideOriginalBody": "false", "originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB", "title": "Re: [tim-janik/beast] Jack driver (#31)", "sections": [ { "text": "", "activityTitle": "**Stefan Westerfeld**", "activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png", "activitySubtitle": "@swesterfeld", "facts": [ ] } ], "potentialAction": [ { "name": "Add a comment", "@type": "ActionCard", "inputs": [ { "isMultiLine": true, "@type": "TextInput", "id": "IssueComment", "isRequired": false } ], "actions": [ { "name": "Comment", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"tim-janik/beast\",\n\"issueId\": 31,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}" } ] }, { "name": "Close pull request", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"PullRequestClose\",\n\"repositoryFullName\": \"tim-janik/beast\",\n\"pullRequestId\": 31\n}" }, { "targets": [ { "os": "default", "uri": "https://github.com/tim-janik/beast/pull/31#issuecomment-426346015" } ], "@type": "OpenUri", "name": "View on GitHub" }, { "name": "Unsubscribe", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 300182398\n}" } ], "themeColor": "26292E" } ]</script>
_______________________________________________
beast mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/beast