I wasn't able to look at the level meter on macos. Is any of the framework available on mac?
IMO either do not enable the websockets at all (no -p port specified, only command line, no UI), or using log filter implemented in branch 3.1 https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7918591 (i.e. commit https://github.com/HEnquist/camilladsp/commit/623c574cfdd15df7475e444c2c67205c3c15c57a )
I have a progress report regarding my CDSP setup. I replaced my old USB sound card with a PreSonus 24c and downloaded the CDSP GUI for my Rpi5. They all work just fine. I like the volume control slider -- it's handier than adjusting the 24c's Main output volume pot. At this point my sound system is pretty simple so much of the GUI's capabilities aren't being used. That may change since I'm looking for a good subwoofer design to build. DML panels don't have great low frequency response so I want to fill in the bottom end.
The GUI is only accessible locally on my Rpi since I always will be listening in the room where the computer is located. I can remotely access the computer via SSH if I need to but the only reason would be to move data around.
With all the different sampling rates the 24c supports I'm thinking of dropping FIR-based equalization in favor of IIR filters. The config files are larger since each filter has its own text-based parameter set but that's OK if it means I only need one config file for each signal source.
The GUI is only accessible locally on my Rpi since I always will be listening in the room where the computer is located. I can remotely access the computer via SSH if I need to but the only reason would be to move data around.
With all the different sampling rates the 24c supports I'm thinking of dropping FIR-based equalization in favor of IIR filters. The config files are larger since each filter has its own text-based parameter set but that's OK if it means I only need one config file for each signal source.
OK...
CDSP is now running without gui... this seems to be enough to make sure, that we don't catch all the socket messages.
Last edited:
at the moment it's running without issues...
Maybe it was the usb port... it was connected to the front ports and next to the port is a wlan dongle?!
Maybe it was the usb port... it was connected to the front ports and next to the port is a wlan dongle?!
OK... problems coming back!
It is some kind of a rhythmic "chirp" sound together with some crackling. rhythmic means: it is there for some seconds... some seconds no "chirp" and so on.
problem appears maybe last 2 minutes... but can't see anything special there ;(
It is some kind of a rhythmic "chirp" sound together with some crackling. rhythmic means: it is there for some seconds... some seconds no "chirp" and so on.
problem appears maybe last 2 minutes... but can't see anything special there ;(
I don't see anything bad in the log, strange! You should be able to disable the resamples though, you are running 96 kHz all the way through and the Digiface clock source is set to the input, right? Then there is no need for resampling.
It's really hard to describe artifacts in the sound. Can you record a short bit of it? Just with a phone is enough.
It's really hard to describe artifacts in the sound. Can you record a short bit of it? Just with a phone is enough.
Yes, still on input.
i disabled resampling now. What about rate adjust?
What do you think about trying another PC? Maybe a USB Bus problem?
i disabled resampling now. What about rate adjust?
What do you think about trying another PC? Maybe a USB Bus problem?
You can disable it. There is nothing to adjust now so it doesn't really matter, you just get some log messages about it if you leave it enabled.
I wouldn't think it makes any difference, but then again I don't have any idea of what is wrong so might be worth a try.
To be honest, if you want to avoid the unreliable and time-wasting trial/error , I think you should read the CDSP documentation https://github.com/HEnquist/camilladsp/blob/master/README.md , at least the section about rate adjust. Henrik put a lot of effort into documenting the purpose and features of that. There you will learn why and when to use rate adjust, rate adjust + async resampler, no rate adjust. Especially in your case when you have a direct indication NoLock vs. Sync in your soundcard the choices are very relevant.
Again, trial/errors lead to wasted time and no reliable results. First I would recommend to configure CDSP to fit your chain. For that you need to make sure you know what your card reports - Lock or Sync? Please post 'amixer -c YOUR_CARD_NAME contents' here when your chain runs, so that we can see what is really going on, instead of incomplete alsamixer screenshots. PLEASE do not use screenshots but copy text from the terminal into the 'code' markup, so that the dump is legible, searchable on the page, and indexable/searchable by this forum/google for future reference.
After we together confirm CDSP is configured correctly for your running chain, and audible artifacts still occur, then step-by-step diagnostics of your chain would be due. I would suggest to start from the SPDIF receiver - capturing from the capture device to a file and subsequent listening, to make sure the incoming stream is OK.
If you want to avoid listening, play a pure tone instead and make sox spectrogram - with one look you can review minutes of recording for any inconsistency. Very handy for checking for artefacts - for sensitivity see e.g. https://www.diyaudio.com/community/threads/fft-of-digital-loopback.420045/post-7849290 . It's important to choose a frequency which does not align its sine period with the chunksize/period, to make sure one lost chunk produces a visible corruption of the spectrum (in other words so that the chunks (periods etc.) do not start/end with complete sine wave exactly). E.g. playing 971Hz instead of 1kHz, just in case.
Last edited:
That's why i am asking and not just doing it.
It's clear, that the way i go ist far away from your way... but please take in mind: Linux and deeper knoladge of audio chain inside the computer is knew to me... i don't know whre to search.
Searching for rate adjust in the manual is resulting in so many differnt stages, that i have no idea what i should do... thats why i ask!
I am working in the event industry, where we have a fixt date and time where doors get open... so, whe i have i problem, i start to think about where the problem is coming from... and i try out what i think could be the solution... and up to now: i never had an event, what was not ready on door open.
So, going this way is not because i want ignore your or hendriks work... its just how i have learnt do fix problems.
And what i can tell you: a lot of times, just using a different hardware was doing the trick.
I totaly agree, but how can i know this? I am totaly new on Linux. I am not used to work on the command line.
Next: the PC i am using at the moment is not planed to be the one i will use finaly. I choosed it, because it was there...
So maybe it is a good idea to change to the device i like to use at the end. Plan is Pi5 because of multi channel.
Next is, that a pi seems to be a very often used device here, what also means: much more knoledge and experince in case of problems.
Good idea... will try to find out, how it works... sox is again a complete new world to me 😉
I know it's not simple, and I very much appreciate your eagerness to learn the principles, hats off.
Just run that command when you chain is running, so that we see everything reported by the soundcard. Then copy the output to clipboard and paste here to the code markup, that's it.
There is no issue with your PC, CDSP will run identically on RPi. But of course the I2S playback device will be asynchronous to the spdif capture via your soundcard - will need to be considered in the CDSP config.
There are many sox tutorials online https://www.google.com/search?q=sox+tutorial , e.g. https://www.audiosciencereview.com/...to-sox-audio-tool-as-a-signal-generator.4242/, https://billposer.org/Linguistics/Computation/SoxTutorial.html ,