At Thu, 16 Oct 2014 08:39:14 -0600,
Shuah Khan wrote:
>
> On 10/16/2014 08:16 AM, Takashi Iwai wrote:
> > At Thu, 16 Oct 2014 08:10:52 -0600,
> > Shuah Khan wrote:
> >>
> >> On 10/16/2014 08:01 AM, Takashi Iwai wrote:
> >>> At Thu, 16 Oct 2014 07:10:37 -0600,
> >>> Shuah Khan wrote:
> >>>>
> >>>> On 10/16/2014 06:00 AM, Lars-Peter Clausen wrote:
> >>>>> On 10/14/2014 04:58 PM, Shuah Khan wrote:
> >>>>> [...]
> >>>>>> switch (cmd) {
> >>>>>> case SNDRV_PCM_TRIGGER_START:
> >>>>>> + err = media_get_audio_tkn(&subs->dev->dev);
> >>>>>> + if (err == -EBUSY) {
> >>>>>> + dev_info(&subs->dev->dev, "%s device is busy\n",
> >>>>>> + __func__);
> >>>>>
> >>>>> In my opinion this should not dev_info() as this is out of band error
> >>>>> signaling and also as the potential to spam the log. The userspace
> >>>>> application is already properly notified by the return code.
> >>>>>
> >>>>
> >>>> Yes it has the potential to flood the dmesg especially with alsa,
> >>>> I will remove the dev_info().
> >>>
> >>> Yes. And, I think doing this in the trigger isn't the best.
> >>> Why not in open & close?
> >>
> >> My first cut of this change was in open and close. I saw pulseaudio
> >> application go into this loop trying to open the device. To avoid
> >> such problems, I went with trigger stat and stop. That made all the
> >> pulseaudio continues attempts to open problems go away.
> >
> > But now starting the stream gives the error, and PA would loop it
> > again, no?
> >
> >
> >>> Also, is this token restriction needed only for PCM? No mixer or
> >>> other controls?
> >>
> >> snd_pcm_ops are the only ones media drivers implement and use. So
> >> I don't think mixer is needed. If it is needed, it is not to hard
> >> to add for that case.
> >
> > Well, then I wonder what resource does actually conflict with
> > usb-audio and media drivers at all...?
> >
>
> audio for dvb/v4l apps gets disrupted when audio app starts. For
> example, dvb or v4l app tuned to a channel, and when an audio app
> starts. audio path needs protected to avoid conflicts between
> digital and analog applications as well.
OK, then concentrating on only PCM is fine.
But, I'm still not convinced about doing the token management in the
trigger. The reason -EBUSY doesn't work is that it's the very same
error code when a PCM device is blocked by other processes. And
-EAGAIN is interpreted by PCM core to -EBUSY for historical reasons.
How applications (e.g. PA) should behave if the token get fails?
Shouldn't it retry or totally give up?
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
