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 18:25:38 +0900 [thread overview]
Message-ID: <517E3C92.3050801@sakamocchi.jp> (raw)
In-Reply-To: <517E1383.3000603@ladisch.de>
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
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
next prev parent reply other threads:[~2013-04-29 9:25 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 [this message]
2013-04-29 12:38 ` Takashi Sakamoto
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=517E3C92.3050801@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 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.