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
next prev parent 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