[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160816091611.GA25819@shlinux2>
Date: Tue, 16 Aug 2016 17:16:11 +0800
From: Peter Chen <hzpeterchen@...il.com>
To: Ruslan Bilovol <ruslan.bilovol@...il.com>
Cc: Felipe Balbi <balbi@...nel.org>, Daniel Mack <zonque@...il.com>,
Jassi Brar <jassisinghbrar@...il.com>,
Clemens Ladisch <clemens@...isch.de>,
Jonathan Corbet <corbet@....net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-usb@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] USB Audio Gadget refactoring
On Sun, Aug 14, 2016 at 01:21:21AM +0300, Ruslan Bilovol wrote:
> I came to this patch series when wanted to do two things:
> - use UAC1 as virtual ALSA sound card on gadget side,
> just like UAC2 is used so it's possible to do rate
> resampling
> - have both playback/capture support in UAC1
>
> Since I wanted to have same behavior for both UAC1/UAC2,
> obviously I've got an utility part (u_audio.c) for
> virtual ALSA sound card handling like we have
> for ethernet(u_ether) or serial(u_serial) functions.
> Function-specific parts (f_uac1/f_uac2) became almost
> as storage for class-specific USB descriptors, some
> boilerplate for configfs, binding and few USB
> config request handling.
>
> Originally in RFC [1] I've posted before, there was
> major change to f_uac1 after that it couldn't do
> direct play to existing ALSA sound card anymore,
> representing audio on gadget side as virtual
> ALSA sound card where audio streams are simply
> sinked to and sourced from it, so it may break
> current usecase for some people (and that's why
> it was RFC).
>
> During RFC discussion, it was agreed to not touch
> existing f_uac1 implementation and create new one
> instead. This patchset (v2) introduced new function
> named f_uac1_newapi and doesn't touch current f_uac1
> implementation, so people still can use old behavior
>
> Now, it's possible to use existing user-space
> applications for audio routing between Audio Gadget
> and real sound card. I personally use alsaloop tool
> from alsautils and have ability to create PCM
> loopback between two different ALSA cards using
> rate resampling, which was not possible with previous
> "direct play to ALSA card" approach in f_uac1.
>
> While here, also dropped redundant platform
> driver/device creation in f_uac2 driver (as well as
> didn't add "never implemented" volume/mute functionality
> in f_uac1 to f_uac1_newapi) that made this work even
> easier to do.
>
> This series is tested with both legacy g_audio.ko and
> modern configfs approaches under Ubuntu 14.04 (UAC1 and
> UAC2) and under Windows7 x64 (UAC1 only) having
> perfect results in all cases.
>
I find UAC2 (UAC1 is ok) support is not well with the latest mainline
kernel w/o your patch set. The windows7 can't install the driver
successfully and the playback shows underrun (using local codec)
using Linux host.
Do you use the unchanged mainline kernel?
My configfs parameters like below:
echo 2 > functions/uac2.1/c_ssize
echo 48000 > functions/uac2.1/c_srate
echo 3 > functions/uac2.1/c_chmask
echo 2 > functions/uac2.1/p_ssize
echo 48000 > functions/uac2.1/p_srate
echo 3 > functions/uac2.1/p_chmask
Console output:
root@...6qdlsolo:~# arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 &
[1] 859
root@...6qdlsolo:~#
root@...6qdlsolo:~# Recording WAVE 'stdin' : Signed 16 bit Little
Endian, Rate 48000 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
underrun!!! (at least 36.634 ms long)
underrun!!! (at least 36.117 ms long)
underrun!!! (at least 42.132 ms long)
underrun!!! (at least 40.157 ms long)
underrun!!! (at least 36.207 ms long)
underrun!!! (at least 39.173 ms long)
underrun!!! (at least 36.119 ms long)
underrun!!! (at least 36.164 ms long)
--
Best Regards,
Peter Chen
Powered by blists - more mailing lists