Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Pavel Hofman <pavel.hofman@insite.cz>
Cc: ALSA Developers <alsa-devel@alsa-project.org>
Subject: Re: AK4114 - capturing spdif input stops the stream
Date: Fri, 14 Mar 2008 17:18:25 +0100	[thread overview]
Message-ID: <s5hfxuts2i6.wl%tiwai@suse.de> (raw)
In-Reply-To: <47D97E0A.1080400@insite.cz>

At Thu, 13 Mar 2008 20:18:34 +0100,
Pavel Hofman wrote:
> 
> Takashi Iwai wrote:
> > At Thu, 13 Mar 2008 13:49:20 +0100,
> > Pavel Hofman wrote:
> >> Takashi Iwai napsal(a):
> >>> At Wed, 12 Mar 2008 23:50:08 +0100,
> >>> Pavel Hofman wrote:
> >>>> Hi,
> >>>>
> >>>> here is my scenario:
> >>>>
> >>>> ICE1724 card, trying to record from SPDIF input via AK4114, ICE1724 
> >>>> slaved to SPDIF clock from the receiver.
> >>>>
> >>>> The card detects SPDIF input rate correctly (in my case ESI Juli where 
> >>>> AK4114 is provided with independent clock signal to enable the rate 
> >>>> detection). Let's say it is 192000.
> >>>>
> >>>> Now I want to arecord the input stream, let's say in CD quality, using 
> >>>> the plug plugin. The command fails, because of the check in ak4114.c:
> >>>>
> >>>> res = external_rate(rcs1);
> >>>> 	if (!(flags & AK4114_CHECK_NO_RATE) && runtime && runtime->rate != res) {
> >>>> 		snd_pcm_stream_lock_irqsave(ak4114->capture_substream, _flags);
> >>>> 		if (snd_pcm_running(ak4114->capture_substream)) {
> >>>> 			printk(KERN_DEBUG "rate changed (%i <- %i)\n", runtime->rate, res);
> >>>> 			snd_pcm_stop(ak4114->capture_substream, SNDRV_PCM_STATE_DRAINING);
> >>>> 			res = 1;
> >>>> 		}
> >>>> 		snd_pcm_stream_unlock_irqrestore(ak4114->capture_substream, _flags);
> >>>> 	}
> >>>>
> >>>> The stream gets stopped because res = 192000 and runtime->rate = 44100.
> >>>>
> >>>> The problem is that the capture device still offers all the available 
> >>>> rates, instead of the single SPDIF input one. Thus, the plug plugin is 
> >>>> not forced to convert from 192000 to 44100 and runtime->rate is 44100 
> >>>> instead of 192000.
> >>>>
> >>>> Of course recording at 192000 works fine.
> >>>>
> >>>> What would be the best way to force the SPDIF capture device to offer 
> >>>> (advertise) only the current rate? This functionality would have to be 
> >>>> applicable only to the few cards correctly detecting incoming rate 
> >>>> (unlike most ice1724 cards without independent clock in slave mode).
> >>> What about to call snd_ak4114_check_rate_and_errors() at PCM open?
> >>> You can pass AK4114_CHECK_NO_RATE to flags argument to skip the check
> >>> there, at least.
> >>>
> >>>
> >> Well, I would not want to skip the check for cards with functioning rate 
> >> detection. Plus snd_ak4114_check_rate_and_errors gets called 
> >> periodically afterwards.
> > 
> > Yes, but the check there is simply useless at open.  It's only for
> > running states.  snd_ak4114_external_rate() would be simler, then.
> > 
> >> It would be great if the driver in slaved-clock mode cut its list of 
> >> native sample rates to the only one currently fed to SPDIF input and 
> >> detected by AK4114. A routine doing this would be called when switching 
> >> clock to the slaved-clock mode and called again in 
> >> snd_ak4114_check_rate_and_errors() when any change in input rate is 
> >> detected (and the stream is not running). Going back to master-clock 
> >> mode would restore the existing list of all the rates.
> >>
> >> In case of input sample rate change when the PCM stream is running, the 
> >> stream would be stopped. This is already implemented in the current 
> >> version of snd_ak4114_check_rate_and_errors()
> >>
> >> Unfortunately, I do not know how to change the rates list properly not 
> >> to break something. If it is only about changing the HW params struct, 
> >> that would be trivial.
> > 
> > Suppose that the slave <-> master mode change doesn't happen during
> > the stream is opened, it's relatively easy.  So far, ice1724.c doesn't
> > call spdif.ops.open/close callbacks.  Call them in *_spdif_open/close
> > functions with NULL check. Then add open hook in juli.c so that you
> > can change rates_min and rates_max to the currently detected rate at
> > open...
> > 
> > Well, it's faster to write a patch than texts.
> > 
> > 
> 
> 
> .......
> 
> Takashi, thanks for the patch, it works flawlessly.

OK, now committed to HG tree.

> Another issue - when the external clock changes rate and the stream is 
> running (typically when starting the source playback which switches the 
> source card (and its SPDIF-OUT) to a different frequency), the target 
> card detects the change and the capture stream is stopped in 
> snd_ak4114_check_rate_and_errors() by
> 
> snd_pcm_stop(ak4114->capture_substream, SNDRV_PCM_STATE_DRAINING);
> 
> How should recording applications behave with stream in this mode? I 
> would expect arecord to close, but it does nothing. Is this correct 
> behaviour?

It's supposed to be drained then stopped.  Maybe something wrong in
the handling of DRAINING state in the capture direction.

Anyway, it's a bit strange situation as is.  Since the sample rate is
changed, you can't call simply prepare again like normal errors...


Takashi

  reply	other threads:[~2008-03-14 16:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 22:50 AK4114 - capturing spdif input stops the stream Pavel Hofman
2008-03-13  7:50 ` Takashi Iwai
2008-03-13 12:49   ` Pavel Hofman
2008-03-13 13:57     ` Takashi Iwai
2008-03-13 14:11       ` Pavel Hofman
2008-03-13 19:18       ` Pavel Hofman
2008-03-14 16:18         ` Takashi Iwai [this message]
2008-03-14 17:15           ` Pavel Hofman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hfxuts2i6.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=pavel.hofman@insite.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox