JamKazam stops on startup if audio gear ihas frequency set to 48000 (48K)

[DEMandell]

I all , i'm new of the forum so i'm not sure if this is the right place for this kind of topic...


I have found that on win10 (that usually runs audio 44K by default ) ...  if i set my audio gear to 48K ...

when i try to start jamkazam,... it stop with a little white blank dialog in the middle of the screen ( i guess it tries to test the configuration at that stage.)
If i set my audio gear at 44100 (44k) jamkazam starts OK .... and then , when subsequentrlyi start a session it correctly turns audio gear frequency to 48K (as i configured my audio gear in jamkazam)


note that i've already set all other win10 apps and also the default in control panel to my audio gear at 48K  and i ìve no issues with any other programs ...(zoom,teams,skype,cubase,reaper,jamulus, windows audio etc)...

this is annoing because i've to to change audio frequency before running  jamkazam ... knowing that jamkazam is really able to do that (later it works at 48K without any problem.... the fault is only when it start)

tks in adv for any suggestion or help to avoid this ...

I have found exactly the same problem with two different audio interfaces, and as far as I can tell this is a bug either in JamKazam or in its underlying audio software, PortAudio.

Under Windows 10, when a device is set to any sampling rate other than 44100, it either causes a problem in PortAudio or JamKazam such that JamKazam  fails to read a response from PortAudio, resulting in JamKazam seeing no audio devices at all. When this happens on startup, it causes JamKazam to hang while trying to start its client (a background process that handles audio and streaming). If you set your audio device back to 44100, start JamKazam, and then change the device's sample rate from its own control panel, then all audio devices become invisible to JamKazam. Changing the rate back on the device's control panel will make all audio devices appear again.

I have also confirmed your observation that using JamKazam to change the sample rate instead of a device's own control panel will (usually) work, but then when you start it next time, your audio interface will remember the last sample rate it was set to, and JamKazam will again fail to start.

In my testing I was able to run my interface at both 48k and 96k if the rate change was made from within JamKazam.

I will try to figure out how to file a bug report so we can get this fixed.

---

I all , i'm new of the forum so i'm not sure if this is the right place for this kind of topic...


I have found that on win10 (that usually runs audio 44K by default ) ...  if i set my audio gear to 48K ...

when i try to start jamkazam,... it stop with a little white blank dialog in the middle of the screen ( i guess it tries to test the configuration at that stage.)
If i set my audio gear at 44100 (44k) jamkazam starts OK .... and then , when subsequentrlyi start a session it correctly turns audio gear frequency to 48K (as i configured my audio gear in jamkazam)


note that i've already set all other win10 apps and also the default in control panel to my audio gear at 48K  and i ìve no issues with any other programs ...(zoom,teams,skype,cubase,reaper,jamulus, windows audio etc)...

this is annoing because i've to to change audio frequency before running  jamkazam ... knowing that jamkazam is really able to do that (later it works at 48K without any problem.... the fault is only when it start)

tks in adv for any suggestion or help to avoid this ...

I have found exactly the same problem with two different audio interfaces, and as far as I can tell this is a bug either in JamKazam or in its underlying audio software, PortAudio.

Under Windows 10, when a device is set to any sampling rate other than 44100, it either causes a problem in PortAudio or JamKazam such that JamKazam  fails to read a response from PortAudio, resulting in JamKazam seeing no audio devices at all. When this happens on startup, it causes JamKazam to hang while trying to start its client (a background process that handles audio and streaming). If you set your audio device back to 44100, start JamKazam, and then change the device's sample rate from its own control panel, then all audio devices become invisible to JamKazam. Changing the rate back on the device's control panel will make all audio devices appear again.

I have also confirmed your observation that using JamKazam to change the sample rate instead of a device's own control panel will (usually) work, but then when you start it next time, your audio interface will remember the last sample rate it was set to, and JamKazam will again fail to start.

In my testing I was able to run my interface at both 48k and 96k if the rate change was made from within JamKazam.

I will try to figure out how to file a bug report so we can get this fixed.

I did a bunch more testing and found three audio interfaces that all exhibit this problem. All three are from Avid / M-Audio. Another interface I have, an Echo AudioFire 4, doesn't have this problem.

Is your interface from either Avid or M-Audio?