From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3104C282D8 for ; Fri, 1 Feb 2019 09:21:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A0FD62086C for ; Fri, 1 Feb 2019 09:21:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729283AbfBAJVd (ORCPT ); Fri, 1 Feb 2019 04:21:33 -0500 Received: from lb1-smtp-cloud9.xs4all.net ([194.109.24.22]:42163 "EHLO lb1-smtp-cloud9.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726270AbfBAJVd (ORCPT ); Fri, 1 Feb 2019 04:21:33 -0500 Received: from [IPv6:2001:983:e9a7:1:c10c:bd23:3f0c:b7eb] ([IPv6:2001:983:e9a7:1:c10c:bd23:3f0c:b7eb]) by smtp-cloud9.xs4all.net with ESMTPA id pV0qgRp2MRO5ZpV0rgYDik; Fri, 01 Feb 2019 10:21:30 +0100 Subject: Re: [PATCH v10 0/4] Media Device Allocator API To: shuah , mchehab@kernel.org, perex@perex.cz, tiwai@suse.com Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org References: <481787e7-112a-80dd-228c-2497a12547b9@kernel.org> <7a809bc8-f75e-04e6-f612-f6111c6b5a71@kernel.org> From: Hans Verkuil Message-ID: <7e6dc7f1-f596-22d7-bdd6-b54bd912a40d@xs4all.nl> Date: Fri, 1 Feb 2019 10:21:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <7a809bc8-f75e-04e6-f612-f6111c6b5a71@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfDWfpvQKPOlcLHtrX1Js/0xrrpDL1w3cEUPsT+kY4XXI81HOEjVIfDdONZsoHQqjoUbUKWtsPGzCYwxnqiA6ArPkpvOzI9gygcS+F0IfX0Dm/BBfxhm8 HVcn9jlMS1YiZ+82YGOAZpuG0IW2y37HIILy2OVOoXuXw8pyiWR5rTxYXZ8wSsCbxUbZIaZhDmaoHtm75OnmaYAuR+k83Iig++k2/Sfl8Z1SkaqFnKOx7Cj5 tzL8jXP8DaiaaigPb3yc/7cXLusGICo9nGFU97uryg1KH/QDNLj5tdf8SGPiybVjb1ww/XNefAjZ4G5iYp/CHdxylE1gt5ZAurHb/HPrI1EFLsvqkzNfYGez xKA7YlgVx05tk6MY/2zzTR1nx1bQzh8xUdAnSVU21JoJWJb7FkhexbPPflWYUDygLwdwTebsz67mZkNwbVWGf8Kf0F3Z/0pR3vq/sAXhLzaWPXybK54= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/1/19 1:46 AM, shuah wrote: > Hi Hans, > > On 1/30/19 12:42 AM, Hans Verkuil wrote: >> On 1/30/19 2:50 AM, shuah wrote: >>> On 1/29/19 2:43 AM, Hans Verkuil wrote: >>>> On 1/29/19 12:48 AM, shuah wrote: >>>>> Hi Hans, >>>>> >>>>> On 1/28/19 5:03 AM, Hans Verkuil wrote: >>>>>> Hi Shuah, >>>>>> >>>>>> On 1/24/19 9:32 PM, Shuah Khan wrote: >>>>>>> Media Device Allocator API to allows multiple drivers share a media device. >>>>>>> This API solves a very common use-case for media devices where one physical >>>>>>> device (an USB stick) provides both audio and video. When such media device >>>>>>> exposes a standard USB Audio class, a proprietary Video class, two or more >>>>>>> independent drivers will share a single physical USB bridge. In such cases, >>>>>>> it is necessary to coordinate access to the shared resource. >>>>>>> >>>>>>> Using this API, drivers can allocate a media device with the shared struct >>>>>>> device as the key. Once the media device is allocated by a driver, other >>>>>>> drivers can get a reference to it. The media device is released when all >>>>>>> the references are released. >>>>>>> >>>>>>> - This patch series is tested on 5.0-rc3 and addresses comments on >>>>>>>      v9 series from Hans Verkuil. >>>>>>> - v9 was tested on 4.20-rc6. >>>>>>> - Tested sharing resources with kaffeine, vlc, xawtv, tvtime, and >>>>>>>      arecord. When analog is streaming, digital and audio user-space >>>>>>>      applications detect that the tuner is busy and exit. When digital >>>>>>>      is streaming, analog and audio applications detect that the tuner is >>>>>>>      busy and exit. When arecord is owns the tuner, digital and analog >>>>>>>      detect that the tuner is busy and exit. >>>>>> >>>>>> I've been doing some testing with my au0828, and I am confused about one >>>>>> thing, probably because it has been too long ago since I last looked into >>>>>> this in detail: >>>>>> >>>>> >>>>> Great. >>>>> >>>>>> Why can't I change the tuner frequency if arecord (and only arecord) is >>>>>> streaming audio? If arecord is streaming, then it is recording the audio >>>>>> from the analog TV tuner, right? So changing the analog TV frequency >>>>>> should be fine. >>>>>> >>>>> >>>>> Changing analog TV frequency would be s_frequency. The way it works is >>>>> any s_* calls would require holding the pipeline. In Analog TV case, it >>>>> would mean holding both audio and video pipelines for any changes >>>>> including TV. >>>>> >>>>> As I recall, we discussed this design and the decision was to make all >>>>> s_* calls interfaces to hold the tuner. A special exception is g_tuner >>>>> in case of au0828. au0828 initializes the tuner from s_* interfaces and >>>>> its g_tuner interfaces. Allowing s_frequency to proceed will disrupt the >>>>> arecord audio stream. >>>>> >>>>> Query (q_*) works just fine without holding the pipeline. I limited the >>>>> analog holds to just the ones that are required. The current set is >>>>> required to avoid audio stream disruptions. >>>> >>>> So I am not sure about that ('avoid audio stream disruptions'): if I >>>> stream video AND use arecord, then I can just set the frequency while >>>> streaming. Doesn't that interrupt audio as well? And are you sure changing >>>> the tuner frequency actually disrupts audio? And if audio is disrupted, >>>> are we talking about a glitch or is audio permanently disrupted? >>> >>> I think it is a glitch. I will run some tests and let you know. >>>> >>>> That's basically the inconsistent behavior I noticed: just running arecord >>>> will prevent me from changing the frequency, but if I run arecord and stream >>>> video, then it is suddenly OK to change the frequency. >>> >>> How are you changing frequency? I want to duplicate what you are doing. >> >> v4l2-ctl -f > > I am not seeing the inconsistent behavior. Here are my results. > > 1. Started acecord and while it is running: > > arecord -M -D plughw:2,0 -c2  -f S16_LE -t wav foo.wav > Recording WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo > > 2. Ran v4l2-ctl -f as follows: > > v4l2-ctl -f 700 > VIDIOC_G_TUNER: failed: Device or resource busy > VIDIOC_S_FREQUENCY: failed: Device or resource busy > > Based on the current implementation, it failed with resource > busy as expected. > > 3. Started v4l2-ctl as follows: > >  v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0 > VIDIOC_STREAMON: failed: Device or resource busy Why is this? You have one analog tuner and it delivers independent audio and video streams. I should be able to start/stop audio and video independently. And as mentioned above, if I use v4l2-ctl for video streaming, then start arecord, then that works fine. And I can change the tuner frequency while both are streaming. But doing this the other way around (first start arecord, then v4l2-ctl) then that doesn't work. It makes no sense. Note that v4l2-ctl does not open audio, it solely deals with video. qv4l2 will open both audio and video, but for testing audio and video independently you need to use arecord/v4l2-ctl. In any case, my understanding of how this should work is that both arecord and v4l2-ctl should attempt to lock the analog tuner resource, but they can share it. If DVB is using the tuner, then both arecord and v4l2-ctl should fail with -EBUSY. Same if either of arecord/v4l2-ctl is running, then DVB should fail with -EBUSY. BTW, I won't be able to test anything myself until Feb 9th since I'm abroad and don't have access to my au0828. Regards, Hans > shuah@deneb:/mnt/data/lkml/v4l-utils/utils/v4l2-ctl$ v4l2-ctl -f 700 > VIDIOC_G_TUNER: failed: Device or resource busy > VIDIOC_S_FREQUENCY: failed: Device or resource busy > > Based on the current implementation, it failed with resource > busy as expected. > > 4. After stopping arecord: > > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0 > <<<<<<<<<<<<< 11.88 fps > <<<<<<<<<<<<<<< 13.36 fps > <<<<<<<<<<<<<<< 14.00 fps > <<<<<<<<<<<<<<<< 14.35 fps > <<<<<<<<<<<<<<< 14.57 fps > <<<<<<<<<<<<<<<< 14.71 fps > <<<<<<<<< > > > Worked as expected. > > > 5. After stopping above video streaming: > > arecord -M -D plughw:2,0 -c2  -f S16_LE -t wav foo.wav > Recording WAVE 'foo.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo > > > Worked as expected. > >> >>> >>>> >>>> BTW, I think there was also inconsistent behavior in the order of streaming >>>> audio and video: if I stream video first, then I can stream audio afterwards. >>>> But if I stream audio first, then (if I remember correctly) I can't start >>>> video streaming. >>>> > > Okay this is what I saw: > > While v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0 > > I could start arecord -M -D plughw:2,0 -c2  -f S16_LE -t wav foo.wav > > I ran strace on v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0 > and I didn't see AUDIO holds. The only think of here is that > > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0 > > doesn't open audio device. I didn't see this when tested with other > video apps, (tvtine, xawtv, vlc). When video is streaming, I see > arecord failing with device busy. > > As far I can see, exclusion logic is working correctly. s_freq does > fail now based on the current logic. > > btw I tested all of this on 5.0-rc4 > > thanks, > -- Shuah