Hi. Trying to understand fully how to use the snd-aloop loopback driver, and its intended purpose. Have I found a potential bug? Have I, possibly, got a useful suggestion to improve it? Background: I would like to implement real time DSP on audio files and streamed audio e.g. Spotify, played to a DAC with an asynchronous USB interface, using my own DSP code. I would like to do it 'bit perfect' i.e. no resampling - which should provide marginally better audio quality and allow it to run on a low power PC. This means that the DAC sets the sample rate and the audio player software's sample rate should, effectively, be slaved to it. Ideally I would like an ALSA loopback driver that merely requests audio data from the audio player app in the same quantities as I request data from the loopback driver (with some buffering and a bit of latency obviously). Does such a driver exist? The nearest I am aware of is the snd-aloop driver, which runs at its own rate but has a programmable rate shift adjustment. I have been able to press this into service, dynamically adjusting the rate shift to maintain an approximate FIFO level in my code, effectively slaving the playback sample rate to my desired capture rate - with more complexity and latency than should be necessary. However, I have had a problem. I get occasional 'clicks' in the audio, corresponding to a sequence of zero-value samples that I find in the capture data. This seems to affect my Baytrail chipset PC more than a Pentium P4. It occurs to me that this could be because the PC clock rates are slightly different (and I am using the same USB DAC in both cases). I can detect the problem reliably by playing a file containing a repeating ramp waveform and in my code spotting non-contiguous sample values. The problem occurs maybe once in ten minutes. >From the aloop.c code, I see that rate shift is available for both the capture and playback devices. How useful is this? As far as I can tell, the capture and playback sample rates must be equal (at least on average) to prevent the two streams drifting apart..? Even if the user always sets the playback and capture rates to be equal there may be momentary discrepancies that accumulate. On my Baytrail chipset PC, more rate shift is necessary than for the P4 in order to match the playback rate to the capture rate. Does this explain the clicks? Doing some hacking without really understanding everything about the code, I have modified aloop.c to always make the playback 'delta' match the capture 'delta' and this seems to cure my problem: now the system can go for hours without an error in the capture data. Have I found a possible bug? (although I may be the only person in the world using this functionality anyway!) If there isn't such a thing already, could snd-aloop be officially modified to allow direct slaving of playback to capture sample *counts* (not rates)? The driver would simply relay the capture 'drain count' to the playback 'sink count'. If that is not possible, could the user's application pass count (rather than rate) requests via some other mechanism? Finally, apologies if I am talking complete rubbish, and I have completely got the wrong end of the stick about how this stuff works. I know what I want to do, and have managed to hack a system that works, but there may be much neater ways of achieving it. Thanks for your help in advance. ------------------------------------------------------------------------------ _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
