From: Clemens Ladisch <clemens@ladisch.de>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: alsa-devel@alsa-project.org
Subject: Re: include/uapi/firewire.h for other firewire drivers
Date: Fri, 25 Oct 2013 15:04:16 +0200 [thread overview]
Message-ID: <526A6C50.2000901@ladisch.de> (raw)
In-Reply-To: <526A6092.4030709@sakamocchi.jp>
Takashi Sakamoto wrote:
> About include/uapi/firewire.h, I'd like you to give me an advice.
>
> I'm sorry but I have little knowledgement about Dice chipset. So here
> I want to know what I should do for snd-fireworks/snd-bebob.
The primary purpose is to support control panel/mixer applications,
which should be able to find out which ALSA device corresponds to which
FireWire device.
> The header file includes an interface for users to know its already
> streaming or not, and lock it.
Because every device can have settings that should not be changed while
streaming.
> But for Fireworks/BeBoB, I think checking CMP connections do the same
> thing.
When a control panel wants to change several settings, it should not
need to establish a CMP connection just to be able to prevent the driver
from starting streaming at the same time.
> Current FFADO can be failed when CMP connections on the device are
> established, and ALSA can do the same. (but there are some problems.
> both drivers set sampling rate before checking CMP connections. For this
> I have a plan to post a patch for both FFADO and ALSA.)
This lock is not intended to prevent ALSA/FFADO conflicts.
At the moment, snd-dice and FFADO do not attach to the same devices.
When this is possible, the kernel FireWire framework should be extended
to allow the driver to prevent FFADO from using the device. However, it
would be hard for the kernel to differentiate between FFADO and some
control panel, so I guess FFADO should be changed to not attach to
a device that already has a kernel driver.
> Should I implement the same lock for Fireworks/BeBoB drivers?
Yes.
For Fireworks devices, applications will need to send EFC commands, but
will not be able to allocate the same 0xecc080000000 address, so the
driver needs a SEND_EFC ioctl. (That's the same reason why snd-dice has
DICE_NOTIFICATION.)
Regards,
Clemens
next prev parent reply other threads:[~2013-10-25 13:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 12:14 include/uapi/firewire.h for other firewire drivers Takashi Sakamoto
2013-10-25 13:04 ` Clemens Ladisch [this message]
2013-10-25 14:54 ` Takashi Sakamoto
2013-10-26 5:16 ` Takashi Sakamoto
2013-10-28 8:29 ` Clemens Ladisch
2013-10-31 8:30 ` Takashi Sakamoto
2013-11-01 8:36 ` Clemens Ladisch
2013-11-03 14:20 ` Takashi Sakamoto
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=526A6C50.2000901@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=o-takashi@sakamocchi.jp \
/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;
as well as URLs for NNTP newsgroup(s).