public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Cc: Daniel Mack <zonque@gmail.com>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	Clemens Ladisch <clemens@ladisch.de>,
	Jonathan Corbet <corbet@lwn.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Chen <hzpeterchen@gmail.com>,
	linux-usb@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/3] USB Audio Gadget refactoring
Date: Mon, 29 Aug 2016 11:05:20 +0300	[thread overview]
Message-ID: <874m64dmpr.fsf@linux.intel.com> (raw)
In-Reply-To: <1471466955-30898-1-git-send-email-ruslan.bilovol@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]


Hi,

Ruslan Bilovol <ruslan.bilovol@gmail.com> writes:
> 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.
>
> Comments, testing are welcome.
>
> v3 changes:
>  - renamed u_audio exported symbols so they don't
>    conflict with old f_uac1 if both are built-in.
>
> v2 changes:
>  - do not touch f_uac1, instead created f_uac1_newapi

f_uac1_newapi???? What the hell man? :-s

Sure you can't change f_uac1 to newapi without introducing userland
visible changes? We really don't want to add another copy of f_uac1,
sorry.


-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

  parent reply	other threads:[~2016-08-29  8:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17 20:49 [PATCH v3 0/3] USB Audio Gadget refactoring Ruslan Bilovol
2016-08-17 20:49 ` [PATCH v3 1/3] usb: gadget: f_uac2: remove platform driver/device creation Ruslan Bilovol
2016-08-17 20:49 ` [PATCH v3 2/3] usb: gadget: f_uac2: split out audio core Ruslan Bilovol
2016-08-17 20:49 ` [PATCH v3 3/3] usb: gadget: add f_uac1 variant based on new u_audio api Ruslan Bilovol
2016-08-29  8:05 ` Felipe Balbi [this message]
2017-02-04 14:06   ` [PATCH v3 0/3] USB Audio Gadget refactoring Ruslan Bilovol

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=874m64dmpr.fsf@linux.intel.com \
    --to=balbi@kernel.org \
    --cc=clemens@ladisch.de \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=hzpeterchen@gmail.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=ruslan.bilovol@gmail.com \
    --cc=zonque@gmail.com \
    /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