From: Damien Zammit <damien.zammit@gmail.com>
To: Mark Hills <mark@xwax.org>
Cc: alsa-devel@alsa-project.org, Clemens Ladisch <clemens@ladisch.de>,
Daniel Mack <daniel@zonque.org>
Subject: Re: [alsa-devel] [PATCH] ALSA: usb-audio - Capture and duplex support for Digidesign Mbox 1 sound card.
Date: Sat, 29 Mar 2014 23:27:12 +1100 [thread overview]
Message-ID: <5336BC20.1050806@gmail.com> (raw)
In-Reply-To: <1403282253300.13982@beth>
On 29/03/14 16:01, Mark Hills wrote:
> I'm a bit late to this, but I think a more generic quirk is necessary.
Thanks Mark, I don't know much about other devices, but I have provided
some comments about my latest code:
http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140329/bab4ce5a/attachment-0001.bin
> Or does some kind of spec define that these should be applied to the first
> endpoint and that all will be affected?
I used educated guesses to make the Mbox 1 functional:
I set the altsetting of the interface based on the value provided in the
first endpoint entry of the quirk, (since they must be all the same for
a shared interface):
+ alts = &iface->altsetting[fp[0]->altset_idx];
This works for any device where the interface is shared across multiple
endpoints, right? Otherwise you wouldn't use this new quirk type.
After reading all the quirk data and adding streams one by one, I went
on to configure the interface based on the quirk data for the first entry:
+ usb_set_interface(chip->dev, fp[0]->iface, 0);
+ snd_usb_init_pitch(chip, fp[0]->iface, alts, fp[0]);
+ snd_usb_init_sample_rate(chip, fp[0]->iface, alts, fp[0],
fp[0]->rate_max);
I assumed that the supported rates for all interfaces was the same and
that they could be read from the first endpoint entry in the quirk.
I know, most of the quirk data is ignored, but they share the same
interface so most of it is redundant anyway, isn't it?
I can't see what limitations this multi-endpoint quirk type has that
might need to be adjusted for other devices. Can you provide an example
of a device that uses multiple endpoints within a single interface whose
supported rates differ between endpoints? If you can, then I also think
we need a better model. If you can't, is it because it is impossible?
Damien
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2014-03-29 12:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-26 15:10 [PATCH] ALSA: usb-audio - Capture and duplex support for Digidesign Mbox 1 sound card Damien Zammit
2014-01-26 15:30 ` Damien Zammit
2014-01-26 16:52 ` Clemens Ladisch
2014-01-27 3:02 ` Damien Zammit
2014-03-01 7:40 ` Damien Zammit
2014-03-03 21:01 ` Daniel Mack
2014-03-29 5:01 ` Mark Hills
2014-03-29 12:27 ` Damien Zammit [this message]
2014-03-29 22:57 ` Mark Hills
2014-03-30 3:21 ` Damien Zammit
2014-03-31 17:47 ` Daniel Mack
2014-04-01 2:41 ` Damien Zammit
2014-03-29 5:35 ` Damien Zammit
2014-03-31 17:58 ` Daniel Mack
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=5336BC20.1050806@gmail.com \
--to=damien.zammit@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=daniel@zonque.org \
--cc=mark@xwax.org \
/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