[alsa-devel] [PATCH 3/3] Add handling CMP output connection

[Takashi Sakamoto]

Clemens,

 > The specification was written for the general case where the device
 > that creates the connection might be different from the transmitting
 > and receiving devices.  In that case, the payload size is needed for
 > correct bandwidth allocation.

I'm sure that the general case.

 > In our case, the Linux PC does not have plugs that could be accessed
 > by anybody else.

I'm sure that host system (Linux PC) doesn't have no plugs.

 >  (And I'm not sure if the value set by the Fireworks
 > firmware is correct enough so that we'd want to use it.)

With my Fireworks device, it always report 0, it means 1024 bytes for 
max payload size for output plug. But I'm not sure that it always report 
the same value. Especially at 192.0 kHz, the payload size is over 1024 
bytes but my device supports up to 96.0 kHz...

Actually the target device seems to update the max payload size after 
host connects to CMP output plug because its initial value is zero. Then 
we already allocate isochronous resources and isochronous packet to host 
system. I don't think it better to reallocate them after the connecting.

It's reasonable to ignore the payload field in any processing.


Regards

Takashi Sakamoto

(Apr 29 2013 15:30), Clemens Ladisch wrote:
> Takashi Sakamoto wrote:
>> Then I have a question about handling payload field. In specification,
>> "The payload field shall specify the maximum number of quadlets that
>> may be transmitted in a single isochronous packet for this plug" but
>> actually cheking this field seems to make no sense because there is no
>> checking process in the procedure. I think I can do nothing for
>> payload field.
>
> The specification was written for the general case where the device that
> creates the connection might be different from the transmitting and
> receiving devices.  In that case, the payload size is needed for correct
> bandwidth allocation.
>
> In our case, the Linux PC does not have plugs that could be accessed by
> anybody else.  (And I'm not sure if the value set by the Fireworks
> firmware is correct enough so that we'd want to use it.)
>
>
> Regards,
> Clemens