-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New API methods not backported to headers
repository (Jack1)
#628
Comments
Yes, that would be a good thing to fix. As a workaround in Radium I check
if the symbol jack_get_version_string is in libjack. If it isn't, jack is
most likely V1 (or an old version of V2).
…On Wed, Aug 19, 2020 at 2:18 AM Geoffrey McRae ***@***.***> wrote:
The following defines have not been defined in the shared headers
repository making it impossible to determine the jack version (1 or 2) at
runtime based on the existence of the symbols in the linked library.
https://github.com/jackaudio/jack2/blob/ba28ffa3db9af6e1a911d30135e95f3fdd50c1ba/common/jack/jack.h#L63-L77
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#628>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX3J6NAOTUG7IIXSP42STSBMK6TANCNFSM4QEKKGDQ>
.
|
jack_get_version was a jack2 addition that was never pushed to jack1, intentionally. |
Sure, that sounds fine, but it should at the minimum be declared in the JACK1 header even if it's just a weak symbol that is never resolved. This then avoids the need to use
|
Or alternatively, simply do not use this function. It brings nothing of value to the application or the user. |
If one particular version, or some versions, of jack has a bug that causes
a program to crash, you want to inform about how the user can avoid the
program crashes.
…On Wed, Aug 19, 2020 at 11:11 AM Filipe Coelho ***@***.***> wrote:
Or alternatively, simply do not use this function. It brings nothing of
value to the application or the user.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#628 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX3J54LN25KJRXSNMLWQDSBOJLHANCNFSM4QEKKGDQ>
.
|
I am not looking to use the function, but rather checking for its existence to determine if JACK1 or JACK2 is in use. If you provide some other way to detect which version of JACK is in use at runtime, then this problem goes away. |
I understand that, but really seems the wrong solution. Clients must not care what the jack server version is. jack clients target an API, not a specific version of the server/library. if there is some question in regards to the API, that should be clarified instead. (please open a ticket for a question if that is the case) |
Again, we are not trying to determine what version the server is, we don't care what the version string is, the goal here is to determine which client library is in use. As shown by my other issue (#627) there are some critical differences that break the application implementing it depending on which is in use.
Correct, the flaw exists in the jack client library, so how do we detect which versions on deployed systems are buggy or not? How can we be backwards compatible with broken libraries? |
I think that attitude will cause fewer and fewer to use jack.
For instance, Radium crashes when using jack1 because, jack1 by default
throws out clients that spends too much time. This can happen, for instance
if a plugin misbehaves or a user adds too many plugins, the kernel is not
configured properly, too audio programs are running at once, etc. etc.
There is a limited amount of time in life, as you'll be more and more aware
of the older you get, and it's far more efficient use of time to simply
show a warning if using jack1, than to fix Radium to be able to handle
behavior which hardly anyone experience, because hardly anyone uses jack1
(in addition, jack1 doesn't run on windows, which is the main platform for
radium). In addition I've also always considered this behavior in jack1 to
be wrong.
…On Wed, Aug 19, 2020 at 11:26 AM Filipe Coelho ***@***.***> wrote:
I understand that, but really seems the wrong solution.
Once pipewire becomes more common-place, this version string will be
completely meaningless. I dare say it is already meaningless as it is.
Clients must not care what the jack server version is.
If the client changes behaviour depending on server version, the client is
buggy and should be fixed instead.
jack clients target an API, not a specific version of the server/library.
clients need to be able to cope with any server version, or server
rewrite, or even new codebase for the server.
if there is some question in regards to the API, that should be clarified
instead. (please open a ticket for a question if that is the case)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#628 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIX3J3CNIX3COCDCDEVBFLSBOLE5ANCNFSM4QEKKGDQ>
.
|
The client library is tied to the server version though, a mismatch of client/server is not something that works in the core JACK design. Best approach here is to fix JACK and try to get people with the updated version.
On this case, you can simply inform the user and provide an action to reconnect to JACK.
This is a wrong assumption. There are other jack implementations besides jack1 and jack2 (pipewire is the most common). |
Best approach here is to fix JACK, and then try to get this fixed version to users ASAP. |
I don't know what "pipewire" is though, but it doesn't feel safe to
trust the user to have an updated version of jack, if that's what
pipewire is.
For instance, jack 0.109 was a notorious version of jack that causes
lots of programs to crash. Debian stable included this version of jack
for many years.
If it was 2008-2016 again, I would certainly have wanted to show a
warning in my programs if the user used jack 0.109. There were several
reports of jack_capture crashing because of this, but there was no way
to show a warning about this when jack_capture was started.
…On Wed, Aug 19, 2020 at 11:26 AM Filipe Coelho ***@***.***> wrote:
I understand that, but really seems the wrong solution.
Once pipewire becomes more common-place, this version string will be completely meaningless. I dare say it is already meaningless as it is.
Clients must not care what the jack server version is.
If the client changes behaviour depending on server version, the client is buggy and should be fixed instead.
jack clients target an API, not a specific version of the server/library.
clients need to be able to cope with any server version, or server rewrite, or even new codebase for the server.
if there is some question in regards to the API, that should be clarified instead. (please open a ticket for a question if that is the case)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
That is obvious, so how do we go about detecting a user is running an older/broken version of the client libraries? How do we even inform them that there is an issue and they need to upgrade? |
On Wed, Aug 19, 2020 at 11:43 AM Filipe Coelho ***@***.***> wrote:
The client library is tied to the server version though, a mismatch of
client/server is not something that works in the core JACK design.
Best approach here is to fix JACK and try to get people with the updated
version.
For instance, Radium crashes when using jack1 because, jack1 by default
throws out clients that spends too much time. This can happen, for instance
if a plugin misbehaves or a user adds too many plugins, the kernel is not
configured properly, too audio programs are running at once, etc. etc.
On this case, you can simply inform the user and provide an action to
reconnect to JACK.
Actually, Radium crashes. It was a complicated bug. Easier just to inform
about not using jack1. If jack2 starts behaving like jack1 by default I
will consider stop using jack
.
… |
If jack2 starts behaving like this also it will lead to removing support from QEMU also as this kind of behaviour can not be tolerated. |
Noted. Thing is.. even if we now add such function to jack1, linux distributions will not have it for many years... real case: jack2 is now at 1.9.14, the development version. |
We can determine that the new |
Sorry to say, but your application code is broken. |
If we have runtime access to the client version it will at least allow us to write it to a log and when users report crashes we can correlate what changed that caused things to break, even if it's not a bug in jack itself.
Noted, which is why today a patch set has been developed to work around the bad behavior in JACK2, however changing something so fundamental so late into the game is going to cause problems for many people. We will start getting reports of audio dropouts, even if it can recover, and won't know what the cause was because we can't tell what version of libjack is in use on the user's PC. People that had fully working systems/configurations suddenly will break and not be able to identify why. If you really must make JACK2 evict bad/slow clients, make it an optional parameter of the server at startup. BTW: I fully understand why you would want to evict slow clients, the Looking Glass project has the same requirement for latency reasons, but to force this on people just because you feel it's how things should be is not acceptable as many (including myself) can cope with a hung/slow client as we are not using JACK for production/studio audio. |
On Wed, Aug 19, 2020 at 11:56 AM Filipe Coelho ***@***.***> wrote:
Actually, Radium crashes. It was a complicated bug. Easier just to inform about not using jack1. If jack2 starts behaving like jack1 by default I will consider stop using jack
If jack2 starts behaving like this also it will lead to removing support from QEMU also as this kind of behaviour can not be tolerated.
Sorry to say, but your application code is broken.
To me, it looked like a bug in jack1, but I didn't investigate too
much. But no matter which code is broken, the fundamental problem is
that design of jack1 is broken, in my opinion. So I've chosen not to
spend too much time investigating what cause code running on a broken
design to crash.
Clients need to be able to cope with jack shutdown callback. it is part of the API for a reason.
Just because jack2 does not call it, is meaningless here.
It does handle jack shutdown callback normally. But when jack1 wants
to throw out the client, which it should never do BTW, a weird crash
happens.
jack2 is the bad actor, not jack1.
Sure, that's your opinion, but it creates various problems. Why would
a user like to restart the program or reconnect jack? It's fine
getting a notification that the program spends too much time
processing audio, but why can't the program just clean up by itself?
|
I was kinda agreeing with you until this part.
JACK is not the one crashing, your application is.
This is not a matter of opinion, the original design was made that way on purpose. From what I understand, the big reason jack2 is more permissive in terms of "bad" clients is because of Windows and its lack of realtime capabilities which means sometimes clients can take a big amount of time to do audio processing properly again. Note that JACK will do nothing (in terms of shutdown) if clients behave properly. The issue here is that a single bad client can make the entire audio graph misbehave, which can result in, at least, some terrible audio/noise. |
You misunderstand, I am stating that if you make it start evicting clients due to being too slow, the recovery process will cause an audio dropout. You may not be aware, QEMU is used to run Virtual Machines that emulate sound devices. As you can imagine, being super low latency consistently is a difficult thing to do when CPUs are being shared with the VM. The occasional & rare, latency spike is to be expected.
Where is this documented? Jack2 is still valid until you try to re-connect. If you don't close you get a warning that you didn't and it's "cleaning up"? I digress though, this issue is about obtaining the jack client library version in use... surely you can see that this is such a simple thing to require if only for debugging purposes. |
On Wed, Aug 19, 2020 at 12:13 PM Filipe Coelho ***@***.***> wrote:
it can minimize those.
It does handle jack shutdown callback normally. But when jack1 wants to
throw out the client, which it should never do BTW, a weird crash happens.
JACK is not the one crashing, your application is.
When JACK triggers the shutdown callback, no more processing will happen.
The "client" pointer is also no longer valid. Trying to do something with
the client pointer after this is surely a bad idea.
Yes, I think that's what happens. Clearly jack1 should not delete the
client pointer by itself before the program has had a chance to clean up,
that's just horrible.
Sure, that's your opinion, but it creates various problems. Why would a
user like to restart the program or reconnect jack? It's fine getting a
notification that the program spends too much time processing audio, but
why can't the program just clean up by itself?
This is not a matter of opinion, the original design was made that way on
purpose.
So even if the original design is broken, it's still the correct behavior
because it behaves according to the original design? :-)
… |
Ah yes, that makes sense. Sorry for the confusion
I expected to be like that. This is why I said "If you application has many dropouts, I suggest rethinking how it handles to audio so it can minimize those".
Actually, I was wrong. Sorry again. https://jackaudio.org/api/types_8h.html#a1f461fe99711af7edcb1b73b1315fbb3 but still, trying to do anything with this client pointer after this point does not seem like a good idea.
I get it.. likely will be done anyway since JACK headers eventually should be shared between jack1 and jack2. |
Yes, we are already doing so which is why it is working so well. By no means am I stating we have an issue here currently.
Calling
Sure, by no means do I suggest that version-specific workarounds be the norm either, but at the end of the day if there is a bug in the library and the library won't see an update for months to years on a target distribution that breaks a product so completely, yes a workaround based on version may be required. |
jack1 does not delete the pointer, I was wrong in my assumption.
Terrible way to try to prove your point. In this case though, zombifying/shutting-down a client because it is taking longer than the client timeout set on jack server start is a feature that has been in jack (the API) since the start.
|
On Wed, Aug 19, 2020 at 12:32 PM Filipe Coelho ***@***.***> wrote:
is a feature that has been in jack (the API) since the start.
I guess we value arguments such as "original design" " has been in
jack since the start" very differently.
In my opinion, everything broken design should ideally be thrown out,
and every program should include it's own version of jack to prevent
mismatch between server and client.
|
To be clear, jack2 does if you call |
I do not want to go on too much on this, but while I generally agree with you, those file handling functions do not provide a "close/shutdown" callback like jack does.
Yeah, I really don't like it, but being pragmatic I see sometimes there is just no other way. Alternatively (and this is very ugly, even more so than reading jack client version!!) one could read the contents of |
I agree.
This cannot happen and it does not scale anyway. |
I think you're confusing protocol version with library version. The fix for issue #623 would not change the protocol. It seems you're treating protocol version and library version as one and the same thing, which IMO seems very odd. |
This comment has been minimized.
This comment has been minimized.
how so? protocol changes when data structure changes. library version is just the jack release, which is more or less arbitrary. thing is, with jack2, the data structure can change even within the same protocol and jack version. |
Removing the following code would not affect the compatibility of the library with the server: Lines 107 to 124 in ba28ffa
It shouldn't be, it should be versioned independently for exactly this use case.
Understood, but this is not the issue we are addressing here. |
I agree with @gnif here; there should be a way for clients to check the version i.e. by adding I would even go further and say, every public JACK API function added on one side, should be added on the other side as well, i.e. the API headers should be truly shared. That's the point of the weak API. Because once again being realistic: the status quo between JACK1 vs. JACK2 exists for more than 10 years now, it is not likely to disappear in favour of only one side any time soon. |
That is one of my goals.
jack2 has been the favorite since quite a while now, only a small amount of people still use jack1. I will mention this again soon, likely next month, where/when I plan to call for testing regarding new osx/win binaries and a bit of help for low-hanging tasks. |
I for one will be glad to see JACK1 be officially deprecated simply due to the confusing nature of setting up jack for beginners. |
That's great! Thanks!
I believe it when it became reality. ;) AFAICS the situation is not (yet) much different than it was years ago. There was a common consensus in favour of JACK2 before, and was discarded later on. And the small amount of people still backing JACK1 are actually influential ones. As long as new features are pushed onto JACK1 tree, the overall situation will not get resolved.
I think the following should probably be updated as well then: Quote:
|
I am reopening this, since we should strive for feature parity between jack versions. |
The following defines have not been defined in the shared
headers
repository making it impossible to determine the jack version (1 or 2) at runtime based on the existence of the symbols in the linked library.jack2/common/jack/jack.h
Lines 63 to 77 in ba28ffa
The text was updated successfully, but these errors were encountered: