From: Fabien Chevalier <fabchevalier@free.fr>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] audio & dbus
Date: Tue, 21 Nov 2006 20:23:06 +0100 [thread overview]
Message-ID: <4563521A.1010707@free.fr> (raw)
In-Reply-To: <4561046E.50905@xmission.com>
Hi Brad,
>>> I didn't want the timeout to default to be on since it's only useful in
>>> the case when audio goes over hci.
>> Looks like you lost me there :-(, i didn't understand your last sentence
>
> we may have to modify this timeout plan. What I wanted was for the
> daemon to see when audio transmission was idle and have it put the state
> into "stopped" and close the sco or a2dp audio connection. The plugin
> would be notified via dbus that this had happened.
Ok, i understand this time :-)
However i'm surprised you thought of this can where an application would
just stop sending data, as it's not possible to happen.
ALSA applications are expected to call snd_pcm_pause() if they want to
stop sending data without closing the stream. In practive this is rarely
used, as not all hardware support this feature.
If they don't call snd_pcm_pause(), an underrun will occur, which must
be handle as an error later (i.e. hardware is then in an inconsistent
state).
Could you provide details on why you think this was needed ?
Cheers,
Fabien
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-11-21 19:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 6:14 [Bluez-devel] audio & dbus Brad Midgley
2006-11-16 10:22 ` Marcel Holtmann
2006-11-16 15:48 ` Brad Midgley
2006-11-16 16:03 ` Marcel Holtmann
2006-11-16 16:17 ` Johan Hedberg
2006-11-16 16:45 ` Brad Midgley
2006-11-16 17:18 ` Marcel Holtmann
2006-11-17 19:35 ` Brad Midgley
2006-11-17 19:53 ` Brad Midgley
2006-11-16 19:19 ` Brad Midgley
2006-11-16 19:38 ` Fabien Chevalier
2006-11-16 20:45 ` Brad Midgley
2006-11-16 19:27 ` Fabien Chevalier
2006-11-16 20:36 ` Brad Midgley
2006-11-19 17:20 ` Fabien Chevalier
2006-11-20 1:27 ` Brad Midgley
2006-11-21 19:23 ` Fabien Chevalier [this message]
2006-11-21 21:02 ` Brad Midgley
2006-11-22 11:09 ` Fabien Chevalier
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=4563521A.1010707@free.fr \
--to=fabchevalier@free.fr \
--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 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.