It's good to hear that an 8 channel DAC works perfectly with Roon. However, in my experience Roon struggles with the UltraLite which can process 10 channels at 176.4/192kHz, 18 at 88.2/96kHz and 22 at 44.1/48kHz. And these channel figures have to be specified in CamillaDSP's device config for the UltraLite to play ball.
By Roon struggling I mean that certain device and dsp configuration options are either greyed out or don't appear. Specifically I can't "configure the roon dsp to automatically convert all sample rate to that of the loopback" as that DSP option is greyed out. Your experience strengthens my hunch that it's the channel count that is the biggest problem for Roon. Fortunately Roon is making some choices on its own which make things work (like converting the sample rate to match, despite that option not being set) but I don't like it feeling that it's been left to chance! Hence the question I posted.
Last edited:
Roon scans each device and detects the rates the device supports. If the device supports only one rate, then Roon automatically converts to that rate. Thus no other rate conversion options are available.
Same with channel count. It assumes devices always support a fixed number of channels. So if it detects 8 channels at the beginning with only 192khz rate then that's what it will show as supported.
Same with channel count. It assumes devices always support a fixed number of channels. So if it detects 8 channels at the beginning with only 192khz rate then that's what it will show as supported.
Still if learning such HW exists the next step should be to implement support for the feature so that paying customers can use their HW. Maybe that is what Roon people already do if the problem was reported, I do not know.
The feature is quite obvious because the UAC2 bitrate is limited to some 8Mbytes per second, maybe their UAC2 receiver has a lower total bitrate limit.
The feature is quite obvious because the UAC2 bitrate is limited to some 8Mbytes per second, maybe their UAC2 receiver has a lower total bitrate limit.
Thank's Henrik.
Could it be that the code from post #949 is somewhat corrupted here
I get a lot of syntax error's.
I did try a lot, but cannot make it work.
My python is version 3.8.5.
Could it be that the code from post #949 is somewhat corrupted here
I get a lot of syntax error's.
I did try a lot, but cannot make it work.
My python is version 3.8.5.
Code:
import xml.etree.ElementTree as ET
import sys
import yaml
fname = sys.argv[1]
shortname = fname.rsplit('/')[-1].split('.')[0]
tree = ET.parse(fname)
root = tree.getroot()
filters = {}
for speaker in root:
speakername = speaker.get('location print(f"Speaker: {speakername}")
for filt in speaker:
filt_num = filt.get('number filt_enabled = filt.get('enabled freq = float(filt.find('frequency').text gain = float(filt.find('level').text q = float(filt.find('Q').text print(f"Filter: {filt_num}, enabled: {filt_enabled}, f: {freq}, Q: {q}, gain: {gain}")
filter_name = f"{speakername}_{filt_num}"
filtparams = {"type": "Peaking", "freq": freq, "gain": gain, "q": q}
filtdata = {"type": "Biquad", "parameters": filtparams }
filters[filter_name] = filtdata
config = {"filters": filters}
print(yaml.dump(config))
A more direct integration with REW and its EQ filter section would be wonderful. You stare in awe at the result of an auto EQ optimisation result from REW but hesitate due to the typing effort... If Camilla could import the results coming out of REW would be wonderful... but we have been given so much already so can we ask for more really...
//
//
Ah yes of course, the wonderful CODE block garbled stuff as usual.Could it be that the code from post #949 is somewhat corrupted here
I get a lot of syntax error's.
Try this one: Translate REW xml filter config * GitHub
I think I was confusing the Jriver setup with Roon, the above is not correct. As someone else has already mentioned, Roon automatically converts to the sample rate of the audio device.
For my setup, the roon audio device is the rpi4 alsa loopback which is limited to the sample rate and channel count set by camilladsp config.
The roon audio device sampling frequency and channel count only seem to be updated when you enter the audio device setup menu. So if I change the camilladsp sampling frequency I need to open the roon audio device menu so that it sees the new sampling frequency.
@Henrik... XML converter script is working now, thank's
@Phofman
I will look into this, but i am in doubt if it only will work with usb-c connection on the PI.
- If this is the case i need to make a special usb-c cable, where the powerlines are disconnected, cause i power my Pi directly on the usb-c port by now!
Jesper.
@Phofman
I will look into this, but i am in doubt if it only will work with usb-c connection on the PI.
- If this is the case i need to make a special usb-c cable, where the powerlines are disconnected, cause i power my Pi directly on the usb-c port by now!
Jesper.
Jesper if you have the laptop setup then using the file playback option in REW allows you to play the file on the Pi and record the sweep on another computer.
Making Measurements Scroll down to file playback option
Basically save a pre-recorded sweep, play it back in Camila and with the acoustic timing measurement REW knows when the sweep is starting.
Making Measurements Scroll down to file playback option
Basically save a pre-recorded sweep, play it back in Camila and with the acoustic timing measurement REW knows when the sweep is starting.
Ofcause this must be the way to go It already works (including complete integration with CamillaDSP running on Henrik's RPi4) just requires recompiling kernel for now. Hopefully 5.15 kernel will have all patches required.
You can power your Pi through the GPIO and use the USB-C to connect to the USB host, works OK. I do not have any problem with the power line of the USB cable, supplied by the USB host. The fact is when the main PSU is disconnected, the Pi keeps running on the trickle from the USB-C connector. Then yes, cutting the power wire would be useful (and trivial).
REW seems to create a bit more brutal filters than seemingly needed in order to match the requested target curve. Some 15 dB here and there... For this reason it might be good if one could control the execution order of the filters in order to not clip the signal - this depending a bit on the internal implementation scheme... but it would be wise to executed the damping before the gain filters in general - would it not?
How is it now - execution order and GUI display order?
//
How is it now - execution order and GUI display order?
//
Attachments
Last edited:
Since the parameters for Alsa devices is causing some trouble, I have added som more debug output. It now shows the allowed values for each parameter before trying to set it. This will be included on 0.6.2.
Example output:
Example output:
Code:
Aug 29 23:22:00.343 DEBG Playback: supported channels: [2], module: camillalib::alsadevice
Aug 29 23:22:00.343 DEBG Playback: setting channels to 2, module: camillalib::alsadevice
Aug 29 23:22:00.343 DEBG Playback: supported sample rates: Discrete([44100, 48000]), module: camillalib::alsadevice
Aug 29 23:22:00.343 DEBG Playback: setting rate to 44100, module: camillalib::alsadevice
Aug 29 23:22:00.344 DEBG Playback: supported capture formats: [S16LE, S32LE], module: camillalib::alsadevice
Aug 29 23:22:00.344 DEBG Playback: setting format to S16LE, module: camillalib::alsadeviceYou can use rephase to import the EQ's from REW and generate an FIR filter which Camilla can play. No typing effort required. The only issue would be that it would be sample rate dependant.A more direct integration with REW and its EQ filter section would be wonderful. You stare in awe at the result of an auto EQ optimisation result from REW but hesitate due to the typing effort... If Camilla could import the results coming out of REW would be wonderful... but we have been given so much already so can we ask for more really...
//
Henrik might be able to leverage the xml output to use with Camilla but there is the option to use FIR's now.