[bug] High Fidelity is only using Left input channel


Just fixed a problem with my audio configuration. last week the right channel where missing.
But now i discover that high fidelity is not using the Right channel at all. :frowning:
Double checked it with other input like music. it’s still only using the left channel.
SIgnal input here is always based on line-in signal from mixing device.

I expect that high fidelity is using both input channels, and not only one.

Build 2351


@Richardus.Raymaker is this still happening? We have experienced it before and think we have a fix .




Just installed build 2359
First test turning ‘pan’ to left is ok, turning pan to the right side and the sound is gone.
Did the same with wavesaur running (audio recording/edit tool) the Vu-Meters in the show that i have both channels or left / right if you move the ‘pan’ on the mixer.

So it’s still not working in high fidelity.
Note, did a test with singularity viewer in opensim, and thats sadly only using one channel too :open_mouth:


To note, we talk about Line-In on the sound card.


@Richardus.Raymaker can you tell me more about your audio setup?


@Richardus.Raymaker , do you hear youtube videos in both ears?


Yes i hear all other programs with 2 ears.
The line-in from my sound blaster X-Fi is stereo.
audio editor named wavesaur is showing that and record stereo fine.

My microphone is connected to some external equipment that is connected to a audio mixer (left and right channel) device. From there the line-out is going to the line-in on the sound blaster X-Fi. The external mixer device have the option to pan from left to right or both (center) that’s where i have spotted that once channel is not working.

I now have a webcam for DDE, that one have a stereo microphone. but am pretty sure that also there would high fidelity is only using one channel. but it;s hard to test on that device because you cannot mute one channel.

[DEBUG] [05/12 00:54:04] output  device: “Speakers (Sound Blaster X-Fi Xt”
[DEBUG] [05/12 00:54:04] DEBUG [ “Speakers (Sound Blaster X-Fi Xt” ] [ “Speakers (Sound Blaster X-Fi Xt” ]
[DEBUG] [05/12 00:54:04] Offscreen UI resizing to  1828 x 1080  with pixel ratio  1
[DEBUG] [05/12 00:54:04] The default audio output device is “Speakers (Sound Blaster X-Fi Xt”
[DEBUG] [05/12 00:54:04] The audio output device  “Speakers (Sound Blaster X-Fi Xt” is available.
[DEBUG] [05/12 00:54:04] The desired format for audio I/O is QAudioFormat(24000Hz, 16bit, channelCount=2, sampleType=SignedInt, byteOrder=LittleEndian, codec=“audio/pcm”)
[DEBUG] [05/12 00:54:04] The desired audio format is not supported by this device
[DEBUG] [05/12 00:54:04] The format to be used for audio output is QAudioFormat(48000Hz, 16bit, channelCount=2, sampleType=SignedInt, byteOrder=LittleEndian, codec=“audio/pcm”)

[DEBUG] [05/12 00:54:10] DEBUG [ “Line-In (Sound Blaster X-Fi Xtr” ] [ “Line-In (Sound Blaster X-Fi Xtr” ]
[DEBUG] [05/12 00:54:10] The audio input device  “Line-In (Sound Blaster X-Fi Xtr” is available.

I hope this helps you forward, otherwise we need to talk more. one thing i just notice in the log. The format to be used for audio input is QAudioFormat(48000Hz, 16bit, channelCount=1

channelCount=1 ?? that need to be 2 i think. also and im not alone with that problem i think 24Khz seems a problematic samplerate. Did not more soundcards report 24000Hz as unavailable ?

This is on windows 7 64bit system.

Few other topic’s that have logs from others. some seems to switch back to 1 channel, others keep using 2 channels



Hi Richardus,

As you suggest, it sounds like maybe your sound card doesn’t support our 24 KHz sample rate. That’s not something we can easily reconfigure, but if you’re able to get your hands on a USB audio interface with simple I/O, it should work for you, Something as basic as a Turtle Beach Amiga ought to get the job done.


Then what is the purpose of using SOXR re-sample library? It seemed its entire purpose of it was to handle a sound device that doesn’t support sample rate X using sample rate Y it does support resampled to X.


I have Sound blaster X-Fi. and other sound cards. but not going to use it, because the quality is poor. also the onbboard realtek sound is not good.

Better option is if high fidelity is fixing the problem, im not the only one.


A large part of problem is that, let’s face it, OS X tends to make sound programming easy. Windows is far less forgiving - for example - the SB X-Fi absolutely supports 24KS/S stereo input, what it doesn’t necessarily support is setting a latency parameter lower that it can live with - so - it returns can’t support, not because it can’t do 24KS/S, but because it can’t at x mS latency or with some buffer sizing choice. QT simply returns can not do and the assumption seems to be it’s due to sample rate when in fact it can be any number of other items.

In my case I have a one of kind audio device, built from ground up of my own design for working with software defined radio - it uses very high end ADC/DAC chips, temperature compensated clock oscillator sources for high stability and I wrote its Windows drivers. I can assure that I know exactly what it can and can not do - in case of HF - it reports the non-sense that it can’t operate a 24KS/S stereo sample rate on input, but, that’s absolutely incorrect - what it can’t support is setting a very low latency capture rate. Watching its driver debug output I can clearly see it fails to open due to HF asking for unreasonable parameters in other than sample rate.


One thing i don’t understand, why did High Fidelity did choice for 24000hz and not the more common 22050hz ?


These days 12K, 24K, 48K is more common. Reason for - USB is based upon at 12MHz clock rate that made it easier (cheaper) to build USB compatible sound devices - could use USB clock as ADC/DAC clock, easier packet sending etc.

There’s very little out there made in last few years that does not support 12/24/48K rates - there’s actually more modern PC hardware that does not support 11.025,22.05,44.1 natively - their drivers often resample 12/24/48 to the old CD S/s standard rates.