Logitech C920 causes sample rate = 0?

[alatar]

I have a bit of a weird problem.

A tester reports, that his Logitech C920 web cam causes our standalone plugin to quit directly after starting.

We did some debugging:
Whenever he sets the Logitech web cam as the audio input, the JUCE audio settings dialog reports that no sample rates are available.

Apparently the fallback sample rate is 0 in that case.
So in other words: using the Logitech web cam as an input causes the output sample rate to be 0.
And apparently a sample rate of 0 causes the app to quit immediately after starting.

Anyone else seen this?
The problem also appears, when I give the tester a default JUCE standalone plugin (without any of our own code).
I can see that the assert jassert (sampleRate > 0 && blockSize > 0); is hit lots of times, on line 107 of AudioProcessorPlayer::audioDeviceIOCallback.

The tester is on OSX Mojave, running a stand-alone version of our plugin.
We compile with JUCE v6.0.4.

[yfede]

Has this issue ever been resolved?

A user has just reported that our standalone plugin crashes immediately a Logitech webcam he owns is connected to the system.

I have asked the webcam model and will post updates here, but given the specificity of the issue, I’m inclined to believe it’s the same problem.

It happened on macOS 12.4, ARM64 build with JUCE 6.1.5 (the latest commit before JUCE 7).

[attila]

Just recently a number of commits have been released addressing this issue.

AudioDeviceManager: Take sample rate compatibility into account during default device selection

sampleRate is 0 with Mac Mini M1

I am implementing a host / standalone app. When I create the AudioIODeviceCallback, I get a sample rate of 0 in the audioDeviceAboutToStart(). The AudioIODevice is juce::CoreAudioClasses::AudioIODeviceCombiner I debugged into the juce::CoreAudioClasses::AudioIODeviceCombiner::start() and can see there that the getAvailableSampleRates() returns an empty array. The output is functional, but the samplerate is always 0 which screws up my pipeline (and prevents me fro using the MidiInputCollector…

[kcoul]

+1 I have also experienced this issue with the same camera when testing an Input/Output library I was writing.
I am pretty sure the issue is exclusive to macOS and occurs in the juce_mac_CoreAudio.cpp class, and is some kind of race condition when acquiring the device info. It might have to do with how the device has 0 outputs and 2 inputs. I found that it would wind up trying to create an aggregate device with the previously used device.

[yfede]

For the records, the webcam that is giving the issue to our customer is:

Logitech QuickCam Vision Pro

When I’ll have a chance, I’ll try updating JUCE past those commits and see if they solve the issue

[kcoul]

That’s great to hear, looks like we posted about exactly the same time and I didn’t see your message before posting mine. Will also update and retest the repro steps I had set up for this one.