QSC Q-SYS for loudspeaker management

[goldistan]

Has anyone tried it?
The new QSC "core" products all follow this open architecture. looks like it can do anything as far as audio crossover is concerned.
e.g. this unit:
https://www.qsc.com/products-solutions/q-sys/processing/core-8-flex/

How's the analog quality?

 

[maverickronin]

Has anyone tried it?
The new QSC "core" products all follow this open architecture. looks like it can do anything as far as audio crossover is concerned.
e.g. this unit:
https://www.qsc.com/products-solutions/q-sys/processing/core-8-flex/

How's the analog quality?

Have you found a place that openly advertises a price?

I tired looking into their stuff a bit, but QSC really does not not want to sell to individuals.

 

[mdsimon2]

Spec'd analog performance is poor.

20 dBu max output level is 7.75 V. Assuming 108 dB DR spec is unweighted at full output you are looking at ~31 uV residual noise which is ~96 dB DR at 2 V output. This level of performance is worse than a miniDSP 2X4HD or 4X10HD.

Michael

 

[AnalogSteph]

Mind you, there could still be a PGA lurking inside. That might explain why there's an EIN spec for an output, too. (And if all fails, there's still the option of using analog attenuators.) Converter performance suggests a bunch of CS4272 class devices, possibly CS5364 + 4x CS4382 or something.

 

[apgood]

The core 8 flex and those newer cores are designed mainly for distributed audio applications. If you want something targeted more at recording, broadcast or cinema then look for a 2nd hand Q-Sys Core 250 or 500. They are discontinued so you can probably pick them up for about the same price as the core 8 flex. The 250 & 500 have 8 slots where you can add input and out put cards. You can see their Dynamic Range is supposed to be better than

 

[Krusty09]

If you want to look at another brand go to symetrix . I think you might like it. They been around forever .

 

[Igor Kirkwood]

Spec'd analog performance is poor.

View attachment 172863

20 dBu max output level is 7.75 V. Assuming 108 dB DR spec is unweighted at full output you are looking at ~31 uV residual noise which is ~96 dB DR at 2 V output. This level of performance is worse than a miniDSP 2X4HD or 4X10HD.

Michael

You said mdsimon "Spec'd analog performance is poor."

The question is not to bee "poor" or to be "rich" but it is to be audible or not audible

I am a Sound Engineer and therefore before choosing a QSC Q-SYS Core 110f and knowing if the performance of this one was "sufficient" alone
a blind comparison test between the QSC Q-SYS Core 110f…… and a straight wire
The QSC Q-SYS Core 110f was therefore connected with all its correction and filtering modules at zero except for a "monstrous" double equalization +20 dB and -20 dB (see photo).

Well, no audible difference in a blind test, between the straight wire and the QSC, thus validating the quality of the QSC and in particular its 48 kHz sampling frequency.

In order to be valid, the comparative dynamic test between a straight wire and a QSC Core 110f must take place in an ultra-quiet studio like that of Briare with its background noise of only 15.5 dB

 

[mdsimon2]

You said mdsimon "Spec'd analog performance is poor."

The question is not to bee "poor" or to be "rich" but it is to be audible or not audibleView attachment 262511View attachment 262512View attachment 262513View attachment 262514View attachment 262515

I am a Sound Engineer and therefore before choosing a QSC Q-SYS Core 110f and knowing if the performance of this one was "sufficient" alone
a blind comparison test between the QSC Q-SYS Core 110f…… and a straight wire
The QSC Q-SYS Core 110f was therefore connected with all its correction and filtering modules at zero except for a "monstrous" double equalization +20 dB and -20 dB (see photo).

Well, no audible difference in a blind test, between the straight wire and the QSC, thus validating the quality of the QSC and in particular its 48 kHz sampling frequency.

In order to be valid, the comparative dynamic test between a straight wire and a QSC Core 110f must take place in an ultra-quiet studio like that of Briare with its background noise of only 15.5 dB

I am glad it works for you.

While I agree that audibility is the criteria we should be considering your anecdote does nothing to prove or disapprove the manufacturer provided SNR. If you have a measurement from a high quality ADC indicating the real life noise performance is better please share it. Otherwise there are far too many variables for your anecdote to be useful for someone else in determining if the QSC will have adequate noise performance in their own system.

The reason I compared the noise level to the miniDSP 2X4HD and 4X10 is that those products have rather high noise level. Some people find them acceptable and others do not. Whether or not they will have audible noise depends on gain staging, volume control, ambient noise, speaker sensitivity and listener noise tolerance. I've personally used the 2X4HD in low gain systems with padded tweeters and found it silent, I've also tried it in systems with high gain amplifiers connected directly to a higher sensitivity tweeter and found the hiss unacceptable.

If the QSC truly has 31 uV residual noise as the specs suggest I know that it will have audible noise in my system based on past listening tests. After ~26 dB gain from a relatively low noise Hypex NC252MP amplifier that 31 uV noise from the processor turns in to > 600 uV noise at the amplifier output. In my experience I prefer to keep residual noise at the amplifier output below 200 uV to avoid audible noise issues.

Michael

 

[tehas]

I am glad it works for you.

While I agree that audibility is the criteria we should be considering your anecdote does nothing to prove or disapprove the manufacturer provided SNR. If you have a measurement from a high quality ADC indicating the real life noise performance is better please share it. Otherwise there are far too many variables for your anecdote to be useful for someone else in determining if the QSC will have adequate noise performance in their own system.

The reason I compared the noise level to the miniDSP 2X4HD and 4X10 is that those products have rather high noise level. Some people find them acceptable and others do not. Whether or not they will have audible noise depends on gain staging, volume control, ambient noise, speaker sensitivity and listener noise tolerance. I've personally used the 2X4HD in low gain systems with padded tweeters and found it silent, I've also tried it in systems with high gain amplifiers connected directly to a higher sensitivity tweeter and found the hiss unacceptable.

If the QSC truly has 31 uV residual noise as the specs suggest I know that it will have audible noise in my system based on past listening tests. After ~26 dB gain from a relatively low noise Hypex NC252MP amplifier that 31 uV noise from the processor turns in to > 600 uV noise at the amplifier output. In my experience I prefer to keep residual noise at the amplifier output below 200 uV to avoid audible noise issues.

Michael

I expect I'll purchase something in this line over the next few months (probably after April, since QSC has paused shipping these till April due to component shortages and thus the cost of used pieces has gone wild). If I do purchase, I'll ask Amir if he's willing to test.

 

[tehas]

@mdsimon2 I see you are very active with CamillaDSP - is it possible to replicate the processing features of the QSC Core products with CamillaDSP? This could make for a cheaper, more modular product.
I'd be looking for crossovers, arbitrary FIR and IIR filters, multiband compressors and voltage peak limiters (to protect a DIY subwoofer driver). Is it fairly stable and reliable (its used for protecting a driver, so this is a must)?
Is there an indication of how much capacity of the underlying processor is used? Does it scale across multiple cores?
I'll try out the software myself of course, but I'd love some ideas on the differences between these products from an experienced user.

 

[Geert]

I'd be looking for crossovers, arbitrary FIR and IIR filters, multiband compressors and voltage peak limiters (to protect a DIY subwoofer driver).

FIR and IIR filters all you want in CamillaDSP, but no compressors or limiters. See https://github.com/HEnquist/camilladsp#filters. But you can maybe solve that via a plug-in connected via Jack or Pipewire.

Is it fairly stable and reliable

I never had it fail on me.

 

[mdsimon2]

@mdsimon2 I see you are very active with CamillaDSP - is it possible to replicate the processing features of the QSC Core products with CamillaDSP? This could make for a cheaper, more modular product.
I'd be looking for crossovers, arbitrary FIR and IIR filters, multiband compressors and voltage peak limiters (to protect a DIY subwoofer driver). Is it fairly stable and reliable (its used for protecting a driver, so this is a must)?
Is there an indication of how much capacity of the underlying processor is used? Does it scale across multiple cores?
I'll try out the software myself of course, but I'd love some ideas on the differences between these products from an experienced user.

CamillaDSP can do crossovers / IIR / FIR filters. I've personally run 16K FIR taps per channel with 8 channels at 96 kHz with minimal CPU load on a dedicated RPi4. In the GitHub Henrik gives an example of running 262K taps per channel with 8 channels at 192 kHz on a RPi4 with 55% CPU usage. IIUC it uses one core for processing and one core for resampling.

Compressors / limiters are coming in v1.1 which has not yet been released. There is some discussion of it here -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7015655. It sounds like you can install it now by compiling from the compressor branch.

I switched all of my systems to CamillaDSP over a year ago and have found them extremely stable. No crashing or objectionable noises. In comparison prior to CamillaDSP I ran various miniDSP products and would occasionally have hang-ups or freezes requiring a power cycle when changing / updating configurations.

Probably the biggest issue with CamillaDSP is the latency. For a typical setup it will be ~20 ms. Although you can do some to optimize this with lower chunk sizes you may run in to drop outs if you do. I find the latency works for my audio / video setups but I also do not implement any FIR filters that would cause additional delay.

Michael

 

[tehas]

FIR and IIR filters all you want in CamillaDSP, but no compressors or limiters. See https://github.com/HEnquist/camilladsp#filters. But you can maybe solve that via a plug-in connected via Jack or Pipewire.



I never had it fail on me.

Thank you for pointing me to Pipewire. I had no idea of such a big ecosystem of audio processing applications available on linux. I am exploring

 

[tehas]

CamillaDSP can do crossovers / IIR / FIR filters. I've personally run 16K FIR taps per channel with 8 channels at 96 kHz with minimal CPU load on a dedicated RPi4. In the GitHub Henrik gives an example of running 262K taps per channel with 8 channels at 192 kHz on a RPi4 with 55% CPU usage. IIUC it uses one core for processing and one core for resampling.

Compressors / limiters are coming in v1.1 which has not yet been released. There is some discussion of it here -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7015655. It sounds like you can install it now by compiling from the compressor branch.

I switched all of my systems to CamillaDSP over a year ago and have found them extremely stable. No crashing or objectionable noises. In comparison prior to CamillaDSP I ran various miniDSP products and would occasionally have hang-ups or freezes requiring a power cycle when changing / updating configurations.

Probably the biggest issue with CamillaDSP is the latency. For a typical setup it will be ~20 ms. Although you can do some to optimize this with lower chunk sizes you may run in to drop outs if you do. I find the latency works for my audio / video setups but I also do not implement any FIR filters that would cause additional delay.

Michael

Thanks Michael ! This is great to hear, and in fact that example on diyaudio is basically what I need to do, but for a different product
Repurposing an Rpi and will start exploring CamillaDSP

Is the 20ms latency for Motu Input -> CamillaDSP -> Motu Output? Or for CamillaDSP processing alone? Is it a high minimum latency figure and additional processing only adds incremental latency (of course excluding long FIR filters)?
I don't have a good mental model for latency because things like AVRs basically hide that info from you. Is 20ms considered a lot?
Do you use this in the path of an AVR output to speakers, ie AVR-> CamillaDSP -> Amplifier -> Speakers? How do you handle video sync, since I believe HDMI lip sync wont help in these scenarios?

 

[mdsimon2]

Is the 20ms latency for Motu Input -> CamillaDSP -> Motu Output?

Yes. The exact latency will depend on what processing you do and what specific DAC you use but the CamillaDSP delay will be much more significant than the 2-3 ms delay from the interface.

Is it a high minimum latency figure and additional processing only adds incremental latency (of course excluding long FIR filters)?

Resampling adds 5-10 ms delay depending on chunk size but otherwise I haven't experienced much additional latency with IIR filters. FIR filters obviously can add significant additional latency.

I don't have a good mental model for latency because things like AVRs basically hide that info from you. Is 20ms considered a lot?

IIRC the miniDSP products with Dirac (SHD, DDRC-24, etc) have around 25 ms latency. At a 60 Hz refresh rate you have one video frame every 16 ms, so 20 ms latency means audio is delayed from video by about one frame.

Do you use this in the path of an AVR output to speakers, ie AVR-> CamillaDSP -> Amplifier -> Speakers? How do you handle video sync, since I believe HDMI lip sync wont help in these scenarios?

I use an AppleTV 4K with a HDMI extractor. TOSLINK from the HDMI extractor goes to a OpenDRC-DI which acts as a source selector / ASRC and the HDMI output cable from the extractor goes to my TV. AES from the OpenDRC-DI goes to an Okto dac8 Pro operating in USB / AES mode, the AES input gets routed to a RPi4 running CamillaDSP which applies processing and then routes the 8 processed channels to the Okto for analog output.

I do not notice any lip sync issues with this setup. The AppleTV does have the ability to sync audio / video but I have found no need to use it. It is possible that because I pull the audio signal before the HDMI gets video to the TV that the TV adds some additional delay to the video which helps offset the delay from CamillaDSP.

Michael

 

[radeon]

Yes. The exact latency will depend on what processing you do and what specific DAC you use but the CamillaDSP delay will be much more significant than the 2-3 ms delay from the interface.



Resampling adds 5-10 ms delay depending on chunk size but otherwise I haven't experienced much additional latency with IIR filters. FIR filters obviously can add significant additional latency.



IIRC the miniDSP products with Dirac (SHD, DDRC-24, etc) have around 25 ms latency. At a 60 Hz refresh rate you have one video frame every 16 ms, so 20 ms latency means audio is delayed from video by about one frame.



I use an AppleTV 4K with a HDMI extractor. TOSLINK from the HDMI extractor goes to a OpenDRC-DI which acts as a source selector / ASRC and the HDMI output cable from the extractor goes to my TV. AES from the OpenDRC-DI goes to an Okto dac8 Pro operating in USB / AES mode, the AES input gets routed to a RPi4 running CamillaDSP which applies processing and then routes the 8 processed channels to the Okto for analog output.

I do not notice any lip sync issues with this setup. The AppleTV does have the ability to sync audio / video but I have found no need to use it. It is possible that because I pull the audio signal before the HDMI gets video to the TV that the TV adds some additional delay to the video which helps offset the delay from CamillaDSP.

Michael

Why run CamillaDSP on the pi instead of a pc? wouldnt a PC provide a little bit less latency? You could also playback content via the pc and skipping appletv

 

[tehas]

Resampling adds 5-10 ms delay depending on chunk size but otherwise I haven't experienced much additional latency with IIR filters. FIR filters obviously can add significant additional latency.

Not familiar what resampling is, but if it is not a necessity, happy to skip it

IIRC the miniDSP products with Dirac (SHD, DDRC-24, etc) have around 25 ms latency. At a 60 Hz refresh rate you have one video frame every 16 ms, so 20 ms latency means audio is delayed from video by about one frame.

I use an AppleTV 4K with a HDMI extractor. TOSLINK from the HDMI extractor goes to a OpenDRC-DI which acts as a source selector / ASRC and the HDMI output cable from the extractor goes to my TV. AES from the OpenDRC-DI goes to an Okto dac8 Pro operating in USB / AES mode, the AES input gets routed to a RPi4 running CamillaDSP which applies processing and then routes the 8 processed channels to the Okto for analog output.

I do not notice any lip sync issues with this setup. The AppleTV does have the ability to sync audio / video but I have found no need to use it. It is possible that because I pull the audio signal before the HDMI gets video to the TV that the TV adds some additional delay to the video which helps offset the delay from CamillaDSP.

Michael

this is very good to hear, you have a number of components working together. Other than the latency bit, whats encouraging is that they are stable working together - one of my reasons for wanting to get an integrated dsp solution is well, the integration and the seamless operation that it implies and a fear that cobbling together a variety of pieces would have glitchy behavior

 

[tehas]

Why run CamillaDSP on the pi instead of a pc? wouldnt a PC provide a little bit less latency? You could also playback content via the pc and skipping appletv

Playing back high resolution or HDR video content or lossless atmos/DTS:X content from a PC is in short, a shitshow.

Typical streaming services have many continually changing hoops on what PCs are allowed to stream 1080p or 2160p content. You are not guaranteed to get 4k content- I struggled to get Netflix to stream 4k to my htpc and then gave up and am using my TV app instead.
HDR like dolby vision or HDR10+ just does not work on general purpose PCs - i believe the underlying hardware needs to be licensed, so it will work when you use a laptop and the laptop and its display are licensed and certified, or you use a mac mini and a pro-res display. but random configs or DIY PCs are excluded.

High resolution audio cannot be decoded on PC. Jriver can decode TrueHD (lossless dolby) but not DTS:MA. Nothing on PC can generate atmos channels from TrueHD when streaming videos (dolby reference player can do this for local stored audio). VoidX's Cavern can generate atmos from local playback of lossy dolby, but not from truehd.

The easiest option is to bitstream undecoded audio to an AVR which does decoding, spatial audio generation, etc. - so you cant do any PC based DSP.
I suspect in @mdsimon2 's case the atv4k is outputting lpcm streams and no atmos is involved.

 

[mdsimon2]

Why run CamillaDSP on the pi instead of a pc? wouldnt a PC provide a little bit less latency? You could also playback content via the pc and skipping appletv

I used a Pi because it is cheap, fanless, small and I have several of them. Most of the latency in CamillaDSP is due to chunk size and has nothing to do with processing power.

This is also my main audio / video system and my wife is not going to be fussing around with a PC. The AppleTV allows her to turn on the TV, navigate the AppleTV and control the volume of the Okto all with the AppleTV remote. She can also cast content from her iPhone to the AppleTV. Overall a very user friendly system, she has no idea (and does not care) what CamillaDSP is. All she knows is that when she presses the power button on the remote everything works.

I will agree that if you are not using the GPIO or USB gadget functionality of the RPi a PC or a Mac are good options (I am partial to Mac). I run CamillaDSP on 2012 Mac Mini in my office, it has Firewire ports which allows me to play around with some cheap but decent older audio interfaces like a RME Fireface 800 and a MOTU 896.

Michael

 

[mdsimon2]

this is very good to hear, you have a number of components working together. Other than the latency bit, whats encouraging is that they are stable working together - one of my reasons for wanting to get an integrated dsp solution is well, the integration and the seamless operation that it implies and a fear that cobbling together a variety of pieces would have glitchy behavior

This wasn't the first iteration of the system but it is the one that has stayed due to it's stability, user friendliness and great analog performance.

I started with an OpenDRC-DA8 which is a miniSHARC + miniDAC8 and although it has decent processing power it has a rather noisy DAC, only unbalanced outputs and no volume indication.

I then moved to a DIY miniSHARC platform that used an IanCanada McFIFO / McDualXO as a clock buffer to 4 stereo I2S to AES boards based on the WM8805. This is described in more detail here -> https://www.minidsp.com/forum/hardware-support/18550-minisharc-8-channel-digital-output. This platform was rather expensive at ~$800 + shipping but worked well in to the AES inputs of the Okto. However the McFIFO / McDualXO would result in changing latency due to the FIFO and would need to be reset every few days to prevent lip sync issues. It also took up way more space than a RPi.

The easiest option is to bitstream undecoded audio to an AVR which does decoding, spatial audio generation, etc. - so you cant do any PC based DSP.
I suspect in @mdsimon2 's case the atv4k is outputting lpcm streams and no atmos is involved.

Yes, all these setups are just stereo LPCM and CamillaDSP is used to implement active crossovers.

I do have a Dolby DP562 Decoder which I purchased used for $65 and can decode lossy DD 5.1 and turn it in to 3x stereo AES but I haven't built a system with it. It should also be possible to turn 7.1 LPCM from the AppleTV in to a Meridian HD621 or Audiopraise VanityPro in to 4x stereo AES / SPDIF but I have not personally done it.

Michael