From: alok <develnewbie@gmail.com>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] [PATCH]Dynamic Alternate Setting patch (hci_usb.c)
Date: Tue, 24 Apr 2007 21:43:17 +0530 [thread overview]
Message-ID: <1177431197.18086.18.camel@localhost> (raw)
In-Reply-To: <462E21F0.4080204@vasmac.com>
Jose,
On Tue, 2007-04-24 at 09:27 -0600, Jose Vasconcellos wrote:
> list subscribe wrote:
> > Jose,
> >
> > Hi Alok,
> >
> > This is a good start. There are a few other things to consider:
> >
> > * Are there error conditions in hci_usb_tx_complete that need to
> > be handled?
> >
> >
> > I am not sure what you mean. Since we don't flush submitted URBs,
> > these URBs are handled like normal ones. If their status indicates
> > error the error_tx count will be incremented. What error conditions
> > are u pointing at?
> The outstanding urbs are dequeued and put on a temporary list and
> resubmitted
> after changing the configuration. But there may be an active URB that is
> being
> transmitted that will be reported with an error status.
> hci_usb_tx_complete will
> release this urb so it can't be resubmitted. This may also result in a
> small glitch
> when switching to an alternate.
The submitted URBs are dequeued and put into a temporary list but are
not resubmitted later . Rather after flushing the pending queue , the
temporary list is appended to pending_queue.
So after the setting is changed, we have some previous submitted URBs
which are in the process of transmission followed by URBs which use the
changed settings in the pending queue.
If any urb reports an error, only the tx error count is incremented
(hdev->stat.err_tx++).
And all _urbs are unlinked (whether their urbs return error or not) and
queued to the complete_q queue.
I hope this answers your question.
> >
> > * How do you make sure data for different channels is interleaved?
> >
> >
> > Well , since we know that there can be max 3 SCO channels , we can
> > have 3 separate queues, and use a round robin method to send out the
> > packets from the queues. i am not sure about this idea though. What
> > do u think?
> I think this is the right approach; I found that it's very important to
> do the
> interleaving properly. There is an issue if one of the queues is empty
> (i.e. buffer underrun). What to do in that case? Send silence?
If u hit a underrun on one queue, u ignore that sco channel.What
difference is it going to make if we sent silence packets on that
channel?
I am not sure about this. I have no expertise in audio. if someone can
justify this solution i can implement it.
Alok.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2007-04-24 16:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-24 11:13 [Bluez-devel] [PATCH]Dynamic Alternate Setting patch (hci_usb.c) list subscribe
2007-04-24 13:15 ` Jose Vasconcellos
2007-04-24 15:08 ` list subscribe
2007-04-24 15:27 ` Jose Vasconcellos
2007-04-24 16:06 ` Marcel Holtmann
2007-04-24 16:13 ` alok [this message]
2007-04-24 17:08 ` Jose Vasconcellos
2007-04-24 18:38 ` Marcel Holtmann
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=1177431197.18086.18.camel@localhost \
--to=develnewbie@gmail.com \
--cc=bluez-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