[alsa-devel] [PATCH v3 0/7] ALSA: aloop: Support sound timer as clock source instead of jiffies

Andrew Gabbasov andrew_gabbasov at mentor.com
Wed Nov 20 13:15:08 CET 2019


Hello Takashi,

> -----Original Message-----
> From: Takashi Iwai [mailto:tiwai at suse.de]
> Sent: Thursday, November 14, 2019 8:11 PM
> To: Gabbasov, Andrew
> Cc: alsa-devel at alsa-project.org; linux-kernel at vger.kernel.org; Jaroslav
> Kysela; Takashi Iwai; Timo Wischer
> Subject: Re: [PATCH v3 0/7] ALSA: aloop: Support sound timer as clock
> source instead of jiffies
> 
> On Mon, 11 Nov 2019 12:08:39 +0100,
> Andrew Gabbasov wrote:
> >
> > This patch set is an updated version of patches by Timo Wischer:
> > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-
> March/146871.html
> >
> > This patch set is required for forwarding audio data between a HW sound
> > card and an aloop device without the usage of an asynchronous sample
rate
> > converter.
> >
> > Most of sound and timers related code is kept the same as in previous
> set.
> > The code, related to snd_pcm_link() functionality and its using for
> > timer source setting, is removed (as rejected earlier). The changes in
> this
> > update are mainly related to the parameters handling and some cleanup.
> >
> > The timer source can be initially selected by "timer_source" kernel
> module
> > parameter. It is supposed to have the following format:
> >     [<pref>:](<card name>|<card idx>)[{.,}<dev idx>[{.,}<subdev idx>]]
> > For example: "hw:I82801AAICH.1.0", or "1.1", or just "I82801AAICH".
> > (Prefix is ignored, just allowed here to be able to use the strings,
> > the user got used to).
> > Although the parsing function recognizes both '.' and ',' as a
separator,
> > module parameters handling routines use ',' to separate parameters for
> > different module instances (array elements), so we have to use '.'
> > to separate device and subdevice numbers from the card name or number
> > in module parameters.
> > Empty string indicates using jiffies as a timer source.
> >
> > Besides "static" selection of timer source at module load time,
> > it is possible to dynamically change it via sound "info" interface
> > (using "/proc/asound/<card>/timer_source" file in read-write mode.
> > The contents of this file is used as a timer source string for
> > a particular loopback card, e.g. "hw:0,0,0" (and here ',' can be used
> > as a separator).
> >
> > The timer source string value can be changed at any time, but it is
> > latched by PCM substream open callback "loopback_open()" (the first
> > one for a particular cable). At this point it is actually used,
> > that is the string is parsed, and the timer is looked up and opened.
> > This seems to be a good trade-off between flexibility of updates and
> > synchronizations or racing complexity.
> >
> > The timer source is set for a loopback card (the same as initial setting
> > by module parameter), but every cable uses the value, current at the
> moment
> > of opening. Theoretically, it's possible to set the timer source for
each
> > cable independently (via separate files), but it would be inconsistent
> > with the initial setting via module parameters on a per-card basis.
> >
> > v2:
> > https://mailman.alsa-project.org/pipermail/alsa-devel/2019-
> November/157961.html
> >
> > v3:
> > - Change sound card lookup to use snd_card_ref() and avoid direct access
> >   to sound cards array
> > - Squash commits on returning error codes for timer start and stop
> > - Some locking related fixes
> > - Some code cleanup
> 
> The patch won't work with the latest ALSA timer code found in my
> for-next branch due to the API changes.  Essentially you need to
> rewrite as:
> 	timeri = snd_timer_instance_new(...);
> 	if (!timeri)
> 		no_memory_error;
> 	timeri->flags |= ...;
> 	timeri->ccallback = ...;
> 	....
> 	err = snd_timer_open(timeri, ....);
> 	if (err < 0)
> 		error;
> 

The updated patch set version 4 was sent to mailing list:
https://mailman.alsa-project.org/pipermail/alsa-devel/2019-November/158896.h
tml

It is based on the linux-next repo master branch as of Nov 19, 2019.

Thanks!

Best regards,
Andrew



More information about the Alsa-devel mailing list