Re: [Alsa-user] aloop questions and a possible suggestion

[Clemens Ladisch]

Xover wrote:
> Clemens Ladisch  googlemail.com> writes:
>> Xover wrote:
>>> Clemens Ladisch  googlemail.com> writes:
 It is intended to be used when there is no actual hardware device.
>>>
>>> By way of some background, what is the snd-loop rate shift facility intended
>>> to be used for?
>>
>> To synchronize with some other clock.
>>
>> (Which is what you were doing; but a plugin doesn't require
>> synchronization to begin with.)
>
> The thing is, I see people using the snd-aloop driver as a means to tee off
> audio between an application and a sound card, or even as a means to
> connect one audio source to two sound cards, all over the place. Sometimes
> they set the rate shift manually in an attempt to prevent the inevitable
> drift problems, but of course without 'closing the loop' this will always
> result in disaster eventually.
>
> In the simple requirement of needing to record the output of an audio
> player app while at the same time listening to it on a real (playback-only)
> sound card, what should they do?

Use PulseAudio.  ;-)

Or the file plugin.  (Which isn't easy to use.  It uses either a fixed file
name, or an external script which you have to write yourself.)


Regards,
Clemens

--
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] aloop questions and a possible suggestion

[Xover]

Clemens Ladisch  googlemail.com> writes:

> Use PulseAudio.  
> 
> Or the file plugin:
> http://www.alsa-project.org/alsa-doc/alsa-
lib/pcm_plugins.html#pcm_plugins_file
> (Which isn't easy to use.  It uses either a fixed file name, or an external
> script which you have to write yourself.)

Many thanks Clemens. From what you are saying, there might indeed be a use 
for an ALSA loopback driver that simply relays the 'drain count' to the 
playback side..? Or could PulseAudio be guaranteed to perform this function 
without resampling? Maybe most people aren't worried about the need to 
resample, but I see it as quite important even if only to save CPU power.



--
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] aloop questions and a possible suggestion

[Xover]

Clemens Ladisch  googlemail.com> writes:

> 
> Xover wrote:
> > Clemens Ladisch  googlemail.com> writes:
> >> It is intended to be used when there is no actual hardware device.
> >
> > By way of some background, what is the snd-loop rate shift facility 
intended
> > to be used for?
> 
> To synchronize with some other clock.
> 
> (Which is what you were doing; but a plugin doesn't require
> synchronization to begin with.)
> 
> Regards,
> Clemens
> 
> -
-
> 
The thing is, I see people using the snd-aloop driver as a means to tee off 
audio between an application and a sound card, or even as a means to 
connect one audio source to two sound cards, all over the place. Sometimes 
they set the rate shift manually in an attempt to prevent the inevitable 
drift problems, but of course without 'closing the loop' this will always 
result in disaster eventually. 

In the simple requirement of needing to record the output of an audio 
player app while at the same time listening to it on a real (playback-only) 
sound card, what should they do? Can this all be handled with off-the-shelf 
plugins and without any adaptive resampling? The audio player app may only 
direct its output to 'default', and the audio recording app needs to engage 
with a driver for its source..? Can a few lines of text placed in asoundrc 
solve this problem without resorting to the snd-aloop driver? If you could 
just suggest to me how this would be done, I think a lot of things would 
fall into place for me... 

Many thanks


--
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] aloop questions and a possible suggestion

[Clemens Ladisch]

Xover wrote:
> Clemens Ladisch  googlemail.com> writes:
>> It is intended to be used when there is no actual hardware device.
>
> By way of some background, what is the snd-loop rate shift facility intended
> to be used for?

To synchronize with some other clock.

(Which is what you were doing; but a plugin doesn't require
synchronization to begin with.)


Regards,
Clemens

--
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] aloop questions and a possible suggestion

[Xover]

Clemens Ladisch  googlemail.com> writes:
> 
> It is intended to be used when there is no actual hardware device.
> 
> 

Many thanks Clemens. I will try to learn what plugins do, and how to use 
them.

By way of some background, what is the snd-loop rate shift facility intended 
to be used for? Clearly a great deal of effort has been put into developing 
it, and I have found it useful as a problem solver (I had to slightly modify 
the driver to lock the capture and playback deltas together to make it work 
for me, though). In which scenarios would you imagine it being used 
'properly'?



--
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] aloop questions and a possible suggestion

[Clemens Ladisch]

Xover wrote:
> 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.

This should be done with an external filter plugin:


Pretty much undocumented; for an example, see the speex plugin:


> 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

It is intended to be used when there is no actual hardware device.


Regards,
Clemens

--
___
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

[Alsa-user] aloop questions and a possible suggestion

[Xover]

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user