Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: alsa-devel@alsa-project.org, linux1394-devel@lists.sourceforge.net
Subject: Re: [PATCH 3/3] Add handling CMP output connection
Date: Mon, 29 Apr 2013 21:38:08 +0900	[thread overview]
Message-ID: <517E69B0.2040904@sakamocchi.jp> (raw)
In-Reply-To: <517E3C92.3050801@sakamocchi.jp>

I'm sorry but I correct what I said:

 > 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.

We don't allocate buffer for isochronous packet yet when connecting CMP 
output plug. Then we just gain isochronous resource.

Anyway I don't think it better to reallocate isochronous resource.


Regards

Takashi Sakamoto

(Apr 29 2013 18:25), Takashi Sakamoto wrote:
> 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

  reply	other threads:[~2013-04-29 12:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-28  4:59 [PATCH 0/3] snd-firewire-lib: add handling CMP output connection Takashi Sakamoto
2013-04-28  4:59 ` [PATCH 1/3] rename macros, variables and functions related to CMP plug Takashi Sakamoto
2013-04-28  4:59 ` [PATCH 2/3] Add "direction" member to cmp_connection structure Takashi Sakamoto
2013-04-28  4:59 ` [PATCH 3/3] Add handling CMP output connection Takashi Sakamoto
2013-04-28 12:52   ` Clemens Ladisch
2013-04-29  4:18     ` Takashi Sakamoto
2013-04-29  6:30       ` Clemens Ladisch
2013-04-29  9:25         ` Takashi Sakamoto
2013-04-29 12:38           ` Takashi Sakamoto [this message]
2013-04-29  9:44 ` [PATCH v2 0/3] snd-firewire-lib: add " Takashi Sakamoto
2013-04-29  9:44   ` [PATCH 1/3] rename macros, variables and functions related to CMP plug Takashi Sakamoto
2013-04-29  9:44   ` [PATCH 2/3] Add "direction" member to cmp_connection structure Takashi Sakamoto
2013-04-29  9:44   ` [PATCH 3/3] Add handling CMP output connection 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=517E69B0.2040904@sakamocchi.jp \
    --to=o-takashi@sakamocchi.jp \
    --cc=alsa-devel@alsa-project.org \
    --cc=clemens@ladisch.de \
    --cc=linux1394-devel@lists.sourceforge.net \
    /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