IMO there is none, I have the same soundcard. The adaptive output configuration does not allow syncing to SPDIF input rate.Have you checked clocking options in alsamixer?
Michael
IMO there is none, I have the same soundcard. The adaptive output configuration does not allow syncing to SPDIF input rate.Have you checked clocking options in alsamixer?
Michael
Fantastic, thanks. I've set this to 1536 and so far haven't heard any pops.If you mean buffer fill level the target_level parameter - at 0 it means requesting that the soundcard is constantly deprived of samples. IMO it should be at around 75% of the buffer size. A chart at https://github.com/HEnquist/camilladsp/issues/203#issuecomment-1127293844 tries to depict the timing situation.
Two inputs seems like a really good option, just switch between configs.
Have you seen the devices linked below?
Hifime SPDIF Optical to USB converter, record DAT/minidisc to computer
The UR23 accepts SPDIF optical sources and transfer this to USB. Suitable to record DAT tapes, minidisc or other digital source to a computer.hifimediy.comHifime S2 Digi -Optical SPDIF input and output to USB
The Hifime S2 Digi is an optical in/out device. It has an optical SPDIF input and also an output which can both be used at the same time.hifimediy.com
First one does 96/24 ($25) and second one does 192/32 ($40) although both are optical and in my experience optical doesn't really work above 96 kHz due to receiver / transmitter design constraints.
Is there anyway you can set your fire stick to resample to 96 kHz instead of 192 kHz?
Michael
I see a lot of use cases for these, for instance for people using the wiim mini as streamer that want to do room correction. Can be great if you make it work.Following up on this, devices arrived yesterday and so far very impressed. 96 kHz works great on the cheap one and 192 kHz works great on the more expensive one.
They behave very nicely if TOSLINK signal is removed (unlike the Hifiberry Digi+ I/O).
If they are set to a higher sample rate (say 192 kHz) and a lower sample rate signal is sent to the input CamillaDSP can detect the rate change although the sound gets a bit funky while mismatched. It doesn't work this way if a higher rate than the CamillaDSP rate is provided but it seems to put CamillaDSP in a STALLED state when this happens. All of this makes me wonder if I can write a python script to change configurations to match the input sample rate. Going down in rate would be easy but for going up I would need to trigger on the STALLED state and cycle to the highest input rate of the device so the rate could be properly detected. Not sure it will sound nice when switching rates but I think that will depend on how quickly the rate change can be detected.
Will explore some more and make some measurements to make sure there is nothing terrible going on. Will also try out the digital output of the more expensive device.
Michael
Michael, this is a typical problem with the incoming digital streams which are controlled by the transmitter side.
The branch next11 of CDSP should (certainly will) handle stalling capture/playback devices better. Still, if the driver does not stop and reconfigure the stream with the new rate specification in hw_params (some drivers do, most don't), it's quite tricky to detect and handle the situation.
Alsa drivers for SPDIF input/output should provide AESx ctls, handled by iecset utility (in standard alsa utils). Should your driver provide these PCM-type controls (listed in amixer contents, not in alsamixer which is limited to MIXER type only), you can try reading them with iecset.
IF your driver offers the AES ctl which lists incoming stream rate (read from the SPDIF stream preable, not really measured by the SPDIF receiver), you can try if the ctl supports notifications to subscribers with alsactl monitor. If so, alsactl should print the moment the SPDIF stream is changed to new samplerate (provided the SPDIF transmitter on the remote side puts correct rate info into the preamble which is not always the case).
IF alsactl reacts to the stream change, the situation could be helped with changes to the alsadevice CDSP part I am planning for some nearer future https://github.com/HEnquist/camilladsp/issues/202#issuecomment-1148595342 - CDSP could react to start/stop/rate-change of snd-aloop, usb gadget, and also of the SPDIF incoming stream IF required ctls are available and could be subscribed to.
I am curious about results of the above checks on your HW. Thanks.
amixer -c Audio controls
numid=6,iface=CARD,name='Clock Source 1 Validity'
numid=7,iface=CARD,name='Clock Source 2 Validity'
numid=4,iface=MIXER,name='PCM Playback Switch'
numid=5,iface=MIXER,name='PCM Playback Volume'
numid=3,iface=PCM,name='Capture Channel Map'
numid=1,iface=PCM,name='Playback Channel Map'
numid=2,iface=PCM,name='Playback Channel Map',device=1
amixer -c Rx controls
numid=2,iface=MIXER,name='IEC958 In Capture Switch'
numid=1,iface=PCM,name='Capture Channel Map'
Very good, congrats. I am quite curious what corrected capture rate was logged in the debug mode (on average, it varies significantly due to the calculation principle). ThanksFantastic, thanks. I've set this to 1536 and so far haven't heard any pops.
I spoke too soonVery good, congrats. I am quite curious what corrected capture rate was logged in the debug mode (on average, it varies significantly due to the calculation principle). Thanks
2022-06-22 09:56:58.535246 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:57:08.564644 DEBUG [src/audiodevice.rs:614] Current buffer level: 1009.3, corrected capture rate: 100.0016%
2022-06-22 09:57:08.564990 DEBUG [src/alsadevice.rs:503] Playback buffer level: 1009.3, signal rms: [-43.932182, -42.430912]
2022-06-22 09:57:08.565057 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:57:18.586046 DEBUG [src/audiodevice.rs:614] Current buffer level: 974.7, corrected capture rate: 100.0052%
2022-06-22 09:57:18.586343 DEBUG [src/alsadevice.rs:503] Playback buffer level: 974.7, signal rms: [-45.208946, -40.372013]
2022-06-22 09:57:18.586388 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:57:28.621767 DEBUG [src/audiodevice.rs:614] Current buffer level: 845.1, corrected capture rate: 100.0186%
2022-06-22 09:57:28.622095 DEBUG [src/alsadevice.rs:503] Playback buffer level: 845.1, signal rms: [-43.652477, -42.01655]
2022-06-22 09:57:28.622146 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:57:38.643866 DEBUG [src/audiodevice.rs:614] Current buffer level: 794.4, corrected capture rate: 100.0240%
2022-06-22 09:57:38.644249 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:57:38.644244 DEBUG [src/alsadevice.rs:503] Playback buffer level: 794.4, signal rms: [-49.490974, -50.382904]
2022-06-22 09:57:48.670793 DEBUG [src/audiodevice.rs:614] Current buffer level: 784.7, corrected capture rate: 100.0250%
2022-06-22 09:57:48.671157 DEBUG [src/alsadevice.rs:503] Playback buffer level: 784.7, signal rms: [-45.706066, -45.62338]
2022-06-22 09:57:48.671214 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:57:58.699986 DEBUG [src/audiodevice.rs:614] Current buffer level: 729.3, corrected capture rate: 100.0307%
2022-06-22 09:57:58.700468 DEBUG [src/alsadevice.rs:503] Playback buffer level: 729.3, signal rms: [-59.565437, -60.39319]
2022-06-22 09:57:58.700515 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:58:08.723908 DEBUG [src/audiodevice.rs:614] Current buffer level: 754.8, corrected capture rate: 100.0281%
2022-06-22 09:58:08.724417 DEBUG [src/bin.rs:423] SetSpeed message received
2022-06-22 09:58:08.724404 DEBUG [src/alsadevice.rs:503] Playback buffer level: 754.8, signal rms: [-42.29706, -39.478638]
The parameters that work for me with the icusbaudio7d card (no dropouts, very little latency) and pi 4b, in case you want to give them a try:I spoke too soon
I've since experienced occasional pops and clicks when watching Netflix. I don't know if it's the nature of the audio content that allows me to hear more vs music (quiet scenes?).
I've tried multiple combinations of chunksize, adjust_period and target_level and haven't yet found one that doesn't exhibit this. I've also noticed these pops and clicks more frequently in music since experimenting with different settings.
I'm happy to grab some data if that's useful. You mention debug - are you referring to the command line option for CamillaDSP?
I'll give this a try, thanks. I didn't have much luck with setting the adjust_period so low before, but I see that your target_level is set to 100% of your chunksize, so maybe that makes a difference.The parameters that work for me with the icusbaudio7d card (no dropouts, very little latency) and pi 4b, in case you want to give them a try:
(the very low adjust period really helped in my case when experiencing dropouts. the default is 10 seconds i believe, maybe my 1 second is too little, but it works for me)
View attachment 214072
I'll give this a try, thanks. I didn't have much luck with setting the adjust_period so low before, but I see that your target_level is set to 100% of your chunksize, so maybe that makes a difference.
Do you run a Spotify Connect service on your RPi? I tried raspotify but couldn't get any audio out of it. I wonder how it hooks into CamillaDSP to play alongside TOSLINK input - maybe as a separate device that is added via a mixer?
What is your chunksize? I am afraid of misunderstanding. I talked about 75% of the buffer size, but CDSP uses 2 chunks per buffer. That makes it 150% of chunksize. I am afraid you set it at 75% of the chunksize (i.e. at 37.5% of the buffer). That would be too small.I didn't have much luck with setting the adjust_period so low before, but I see that your target_level is set to 100% of your chunksize, so maybe that makes a difference.
That looks set to continue until raspbian / Raspberry Pi OS shifts to bookworm given the answer in the issue report. I keep meaning to look into the Docker option.Unfortunately there are some issues installing LMS on Ubuntu 22.04 currently, see post a few pages back for more details.
Very useful information, thank you. I think I understand it a little better now. I did indeed have the target_level set to 75% of the chunksize rather than the buffer, which I now understand to be chunksize x 2.What is your chunksize? I am afraid of misunderstanding. I talked about 75% of the buffer size, but CDSP uses 2 chunks per buffer. That makes it 150% of chunksize. I am afraid you set it at 75% of the chunksize (i.e. at 37.5% of the buffer). That would be too small.
100% of chunksize is a very good value too, actually any value at or reasonably above the chunksize makes sense.
Look at the chart of the playback bufffer fill level vs. time. I know it's very complex because the timing in CDSP alsa in/out is that complex. The thick line stepped line is momentary output soundcard buffer fill level at time t (axis x). The avail_min line is buffer fill when the soundcard driver requests new samples (simplified). CDSP sets it at 1 chunksize (= half of the soundcard buffer). The algorithm tries to control the capture-side rate (CDSP either tells the capture device to change its rate or async resamples internally) so that at the moment of audio message (= new samples) delivery from the processing thread to the playback thread the output buffer fill level is as close to the target level as possible. Of course it varies a lot because the time of delivery varies too. Therefore the diffs (diff1, diff2, ...) are averaged for the feedback calculation, a new control algorithm is being tested in new CDSP version etc. The procedure is by its principle rather fragile and needs to be adjusted for every case. I am not sure the method can be made 100.000% reliable, the requirements are just too much conflicting with the real world. I intend to implement generating such charts into CDSP so that the timing can be visualized for any setup but no deadline given
View attachment 214204
I've not seen any mention of buffer underruns in the log unfortunately.@dfgoiuj when you have a drop out have you confirmed that it shows up as a buffer underrun in the CamillaDSP log?
Michael
I've not seen any mention of buffer underruns in the log unfortunately.
I'll have a look into these options, thanks. I imagined it must be possible to simply mix the input in the pipeline somewhere. I wonder if JACK could fit into this somehow.There are two ways I am aware of to integrate a physical capture device in addition to an ALSA loopback capture device in CamillaDSP.
1) Switch configurations between the ALSA loopback as capture device and the physical input as capture device. If you go through this thread you will see some discussion on how this can be done with a MOTU M4 as an example.
2) Have LMS running either on your RPi running CamillaDSP or another RPi on your network and use the WaveInput plugin with your capture device. Your CamillaDSP setup always uses an ALSA loopback as capture device. When you want to play something via TOSLINK just select your TOSLINK USB card on the WaveInput plugin. The disadvantage of this approach is that latency will be far too high to use in audio/video applications. This is also a nice option if you use Spotify as LMS has a Spotify plugin that is easy to use. Unfortunately there are some issues installing LMS on Ubuntu 22.04 currently, see post a few pages back for more details. That same post also has instructions on how to install librespot.
Michael