On Mittwoch, 19. August 2020 00:20:07 CEST Geoffrey McRae wrote: > > Could you please describe in more detail how you ran into this > > situation with > > your 2nd audio device? > > Sure. Run a Windows guest with two audio devices, let it boot up, then > restart > the jack service to trigger the recovery routine, then attempt to use > the 2nd > (non-primary) audio device. Ie, go to windows audio settings to test the > microphone of the second audio device. > > When windows try to use the 2nd audio device it goes through the > recovery > routine triggering this fault.
I still don't quite get how this correlates. So you are forcing a restart of jackd on host side in between, for what purpose? To simulate the Windows client being kicked by jackd? What latencies do you achieve BTW with Windows guests? > I am aware and since these libraries are interchangeable I had assumed > that > JACK1 will have the same fault. If not I suppose we need to detect which > is in > use and change this code appropriately. I haven't checked this in the JACK1 code base yet, but I assume JACK1 does not behave like JACK2 here, because the JACK API is very clear that it is the client's responsibility to free itself. So it looks like a JACK2-only-bug to me. Very weird that there is no jack_client_version() in the shared weak API (i.e. missing on JACK1 side). Best regards, Christian Schoenebeck
