* include/uapi/firewire.h for other firewire drivers
@ 2013-10-25 12:14 Takashi Sakamoto
2013-10-25 13:04 ` Clemens Ladisch
0 siblings, 1 reply; 8+ messages in thread
From: Takashi Sakamoto @ 2013-10-25 12:14 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
Hi Clemens,
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 header file includes an interface for users to know its already
streaming or not, and lock it. But for Fireworks/BeBoB, I think checking
CMP connections do the same thing.
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.)
Should I implement the same lock for Fireworks/BeBoB drivers?
Regards
Takashi Sakamoto
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-10-25 12:14 include/uapi/firewire.h for other firewire drivers Takashi Sakamoto
@ 2013-10-25 13:04 ` Clemens Ladisch
2013-10-25 14:54 ` Takashi Sakamoto
2013-10-26 5:16 ` Takashi Sakamoto
0 siblings, 2 replies; 8+ messages in thread
From: Clemens Ladisch @ 2013-10-25 13:04 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-10-25 13:04 ` Clemens Ladisch
@ 2013-10-25 14:54 ` Takashi Sakamoto
2013-10-26 5:16 ` Takashi Sakamoto
1 sibling, 0 replies; 8+ messages in thread
From: Takashi Sakamoto @ 2013-10-25 14:54 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
Clemens,
Thanks for your quick reply.
> 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.
There is no need to establish connection. The control panel just check
the value of "peer-to-peer connection counter" field in iPCR/oPCR.
But anyway, it's better to give an easy way via the interface. I agree.
> 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.
I'm not a developer for Juju so cannot have any idea for kernel land at
all. But for FFADO, I can put your idea as my future commitment.
> 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.)
Now I understand the reason DICE_NOTIFICATION exists. Dice also have the
similar issue as Fireworks has. For EFC, I'm willing to keep FFADO using
"EFC over AVC" but I found this is not enough for some models with
latest firmware.
Well, you said "The primary purpose is to support control panel/mixer".
But this interface can also be good for prevention of conflict with
FFADO driver. I wonder why you mention this first. Are there any thoughts?
Thanks
Takashi Sakamoto
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-10-25 13:04 ` Clemens Ladisch
2013-10-25 14:54 ` Takashi Sakamoto
@ 2013-10-26 5:16 ` Takashi Sakamoto
2013-10-28 8:29 ` Clemens Ladisch
1 sibling, 1 reply; 8+ messages in thread
From: Takashi Sakamoto @ 2013-10-26 5:16 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
Clemens,
> Because every device can have settings that should not be changed
> while streaming.
For this, I have a further question.
Currently my Fireworks/BeBoB driver give Control interfaces for these
settings, like changing sampling rate, switching digital interface. The
primarry purpose of these is the same, a prevention from stopping
streaming. The secondary purpose is debug codes for these functionality.
But based on firewire.h interface, it is the applications'
responsibility, not drivers'. Is my understanding correct?
Here some devices has "write-only" settings. For such device, my driver
remember these settings. If the applications has such responsibility,
there may be some inconsistency.
Thanks
Takashi Sakamoto
(Oct 25 2013 22:04), Clemens Ladisch wrote:
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-10-26 5:16 ` Takashi Sakamoto
@ 2013-10-28 8:29 ` Clemens Ladisch
2013-10-31 8:30 ` Takashi Sakamoto
0 siblings, 1 reply; 8+ messages in thread
From: Clemens Ladisch @ 2013-10-28 8:29 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
Takashi Sakamoto wrote:
>> Because every device can have settings that should not be changed
>> while streaming.
>
> Currently my Fireworks/BeBoB driver give Control interfaces for these
> settings, like changing sampling rate, switching digital interface.
> The primarry purpose of these is the same, a prevention from stopping
> streaming. The secondary purpose is debug codes for these functionality.
>
> But based on firewire.h interface, it is the applications'
> responsibility, not drivers'. Is my understanding correct?
Yes; the intent is for the kernel driver to handle only those settings
that would be impossible or very difficult to handle with a separate
user space process. (For example, the sample rate is set by the
application on the ALSA device; it would be a bad idea for the driver to
_ask_ the control panel application to change it.)
> Here some devices has "write-only" settings. For such device, my
> driver remember these settings. If the applications has such
> responsibility, there may be some inconsistency.
This is another example of a setting that must be in the kernel driver.
Regards,
Clemens
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-10-28 8:29 ` Clemens Ladisch
@ 2013-10-31 8:30 ` Takashi Sakamoto
2013-11-01 8:36 ` Clemens Ladisch
0 siblings, 1 reply; 8+ messages in thread
From: Takashi Sakamoto @ 2013-10-31 8:30 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
Hi, Clemens,
I have two more questions.
> (For example, the sample rate is set by the application on the
> ALSA device; it would be a bad idea for the driver
> to _ask_ the control panel application to change it.)
I had a doubt that all of models can follow this rule because there are
some models which is not designed for stand-alone use. This type of
device cannot work without connection/streams so I assumed that changing
sampling rate or clock source brings some bad situations.
But now I confirmed all of models which I have can follow this rule.
Related to this, my drivers have PCM rules for auto-adjustment of
rate/channels. Should I remove them and fix rate/channels according to
current sampling rate?
> This is another example of a setting that must be in the
> kernel driver.
As long as I know, this type of device changes its channel formation of
AMDTP stream according to current sampling rate and current digital
input interface. The driver can get current sampling rate by AV/C
command but cannot get current digital input interface because it's
'write-only'.
For this setting, which is better for control panel/mixer application,
control interface or hwdep interface with firewire.h?
Thanks for your patience to answer my questions.
Takashi Sakamoto
(2013年10月28日 17:29), Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>>> Because every device can have settings that should not be changed
>>> while streaming.
>>
>> Currently my Fireworks/BeBoB driver give Control interfaces for these
>> settings, like changing sampling rate, switching digital interface.
>> The primarry purpose of these is the same, a prevention from stopping
>> streaming. The secondary purpose is debug codes for these functionality.
>>
>> But based on firewire.h interface, it is the applications'
>> responsibility, not drivers'. Is my understanding correct?
>
> Yes; the intent is for the kernel driver to handle only those settings
> that would be impossible or very difficult to handle with a separate
> user space process. (For example, the sample rate is set by the
> application on the ALSA device; it would be a bad idea for the driver to
> _ask_ the control panel application to change it.)
>
>> Here some devices has "write-only" settings. For such device, my
>> driver remember these settings. If the applications has such
>> responsibility, there may be some inconsistency.
>
> This is another example of a setting that must be in the kernel driver.
>
>
> Regards,
> Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-10-31 8:30 ` Takashi Sakamoto
@ 2013-11-01 8:36 ` Clemens Ladisch
2013-11-03 14:20 ` Takashi Sakamoto
0 siblings, 1 reply; 8+ messages in thread
From: Clemens Ladisch @ 2013-11-01 8:36 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
Takashi Sakamoto wrote:
> my drivers have PCM rules for auto-adjustment of rate/channels. Should
> I remove them and fix rate/channels according to current sampling rate?
When the clock source is internal or the PC, the driver can change the
sample rate. When the clock source is external, the rate is constrained.
> As long as I know, this type of device changes its channel formation
> of AMDTP stream according to current sampling rate and current digital
> input interface. The driver can get current sampling rate by AV/C
> command but cannot get current digital input interface because it's
> 'write-only'.
>
> For this setting, which is better for control panel/mixer application,
> control interface or hwdep interface with firewire.h?
For settings (like this) that the kernel driver knows about, it should
use a mixer control, because the control interface already has mechanisms
to notify others of changes, and to lock controls.
The hwdep interface is appropriate for commands that must go through the
driver for technical reasons (such as EFC's response address), but where
the driver does not care about the actual meaning of the command.
(For other commands, like A/VC, the application can go directly through
/dev/fw*.)
Regards,
Clemens
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: include/uapi/firewire.h for other firewire drivers
2013-11-01 8:36 ` Clemens Ladisch
@ 2013-11-03 14:20 ` Takashi Sakamoto
0 siblings, 0 replies; 8+ messages in thread
From: Takashi Sakamoto @ 2013-11-03 14:20 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
> When the clock source is internal or the PC, the driver can change
> the sample rate. When the clock source is external, the rate is
> constrained.
OK. That's reasonable.
> For settings (like this) that the kernel driver knows about, it should
> use a mixer control, because the control interface already has mechanisms
> to notify others of changes, and to lock controls.
OK. I select control interface with the same reasons.
> The hwdep interface is appropriate for commands that must go through the
> driver for technical reasons (such as EFC's response address), but where
> the driver does not care about the actual meaning of the command.
>
> (For other commands, like A/VC, the application can go directly through
> /dev/fw*.)
OK. I start to work for hwdep for EFC. I may ask the other questions
later if I have.
Thanks a lot
Takashi Sakamoto
(2013年11月01日 17:36), Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> my drivers have PCM rules for auto-adjustment of rate/channels. Should
>> I remove them and fix rate/channels according to current sampling rate?
>
> When the clock source is internal or the PC, the driver can change the
> sample rate. When the clock source is external, the rate is constrained.
>
>> As long as I know, this type of device changes its channel formation
>> of AMDTP stream according to current sampling rate and current digital
>> input interface. The driver can get current sampling rate by AV/C
>> command but cannot get current digital input interface because it's
>> 'write-only'.
>>
>> For this setting, which is better for control panel/mixer application,
>> control interface or hwdep interface with firewire.h?
>
> For settings (like this) that the kernel driver knows about, it should
> use a mixer control, because the control interface already has mechanisms
> to notify others of changes, and to lock controls.
>
> The hwdep interface is appropriate for commands that must go through the
> driver for technical reasons (such as EFC's response address), but where
> the driver does not care about the actual meaning of the command.
>
> (For other commands, like A/VC, the application can go directly through
> /dev/fw*.)
>
>
> Regards,
> Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-11-03 14:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-25 12:14 include/uapi/firewire.h for other firewire drivers Takashi Sakamoto
2013-10-25 13:04 ` Clemens Ladisch
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
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.