Expose jack_client_t*

[monocasual]

Warning: this is more of a proof of concept than an actual PR.

In Giada we need to take a pointer to the jack_client_t struct in order to provide JACK transport capabilities (start, stop, relocate playhead, change tempo, ...). Unfortunately there's no way to access such structure in "vanilla" RtAudio.

This PR shows you what we are currently doing: a terrible hack that returns a void pointer, just to avoid to pollute RtAudio.h with the jack header (the caller has to cast it back to jack_client_t*).

I'm pretty sure there is a cleaner way to do this, yet getting the jack_client_t handle is useful when you want to do more than playing audio with JACK.

Thoughts?

[radarsat1]

I think RtAudio has always been quite hesitant to include access to pointers of backend objects. Not sure it's "right", but it's hard to come up with a good general way to accomplish this for different platforms. In theory programs that need this may be better off just using the backend API directly (ie. just use JACK itself), but I also understand that sometimes the generalization afforded by RtAudio with only some small tweaks through the pointer may be very convenient.

But I have to ask, (without digging into your source code myself sorry for the laziness), what do you use the jack_client_t for, ultimately? Maybe it is a function that makes sense to expose in a more abstract way.

[monocasual]

The jack_client_t is required by the JACK transport and timebase functions, which enable synchronization between multiple JACK clients. For example, the function below starts the transport for all connected clients:

void jack_transport_start (jack_client_t * client);

Now, I'm aware that providing transport capability is way outside the scope of RtAudio. Also, it's extremely API-specific: there's no such thing on Windows with WASAPI for example. That's why the void pointer trick was the "best solution" I could come up with back then.

[garyscavone]

Would it work to add a member to the StreamOptions structure (perhaps something like "clientPointer") and return the value that way (during the probeDeviceOpen() call)? This would be a bit of a hack but avoid any API changes. There are already a few members of that structure that are only used by a few APIs.

[monocasual]

Would it work to add a member to the StreamOptions structure (perhaps something like "clientPointer") and return the value that way (during the probeDeviceOpen() call)? This would be a bit of a hack but avoid any API changes.

I vote for no API changes, so adding a member to the StreamOptions structure sounds perfect.

[radarsat1]

Well, changing StreamOptions is also an API change ;)

But in any case perhaps it's a good idea to have a void* pointer in there that may be reserved for particular APIs.

This was also handled a bit more eloquently with the "port descriptor" API proposal from a couple of years ago, that is, replacing the ordered-integer port numbers with descriptor classes that could be specialized for each API. But in that case the user was forced to deal with some big changes. Instead we could point to an API-specific object from SteamOptions perhaps which could contain whatever custom objects are useful, but otherwise be completely ignored. It would be nice maybe to have a small inheritence structure though so that user code could use dynamic casting:

api_specific = dynamic_cast<JackAPISpecific*>(options->APISpecific)
if (api_specific != nullptr) ...

Then api_specific would be nullptr both in the case that there is no info, and in the case that it doesn't match the expected API.

[garyscavone]

Yes, it is an API change but one that doesn’t break any existing code. The main issue is that the user would need to be responsible for deleting any possible memory that was allocated in the openStream() function.

…

On Feb 24, 2020, at 7:02 AM, Stephen Sinclair ***@***.***> wrote: Well, changing StreamOptions is also an API change ;) But in any case perhaps it's a good idea to have a void* pointer in there that may be reserved for particular APIs. This was also handled a bit more eloquently with the "port descriptor" API proposal from a couple of years ago, that is, replacing the ordered-integer port numbers with descriptor classes that could be specialized for each API. But in that case the user was forced to deal with some big changes. Instead we could point to an API-specific object from SteamOptions perhaps which could contain whatever custom objects are useful, but otherwise be completely ignored. It would be nice maybe to have a small inheritence structure though so that user code could use dynamic casting: api_specific = dynamic_cast<JackAPISpecific*>(options->APISpecific) if (api_specific != nullptr) ... Then api_specific would be nullptr both in the case that there is no info, and in the case that it doesn't match the expected API. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#232?email_source=notifications&email_token=ABJYDJOQBWXRCDJNGQIF7XDREOZOFA5CNFSM4KWFSH4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMXRL5I#issuecomment-590288373>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJYDJOTCFXAITDULTDAUFDREOZOFANCNFSM4KWFSH4A>. [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#232?email_source=notifications\u0026email_token=ABJYDJOQBWXRCDJNGQIF7XDREOZOFA5CNFSM4KWFSH4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMXRL5I#issuecomment-590288373", "url": "#232?email_source=notifications\u0026email_token=ABJYDJOQBWXRCDJNGQIF7XDREOZOFA5CNFSM4KWFSH4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMXRL5I#issuecomment-590288373", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[radarsat1]

Hm that's a good point and a bit messy.. will think..

[garyscavone]

I don't have a good working Jack environment to test but I think my idea above would work. Create a new void *clientPointer member to the StreamOptions structure with a default value of NULL or 0. If the structure is passed to the probeDeviceOpen() function, then copy the Jack client pointer to it. The Jack client is closed in the closeStream() function, so there shouldn't be any memory issues. I suppose a user could really mess things up by using the jack_client pointer in nefarious ways but that would their problem.

[monocasual]

I'm available for any help with testing on a Jack environment, of course ✋

[ntonnaett]

I don't like this idea of exposing specific backend api. That's contrary to why people use RtAudio in the first place. If the playback functionality would be encapsulated by RtAudio on the other hand, it could be used by other APIs like Ableton Link for example. So it wouldn't be limited to JACK. Maybe you would want to sync JACK and Ableton Link then…