Trying to get headsetd to work with the latest Skype version, I was able to
find some pointers why Skype would freeze when I select the headset device
both as an input and output device.
Try the following command:
$ arecord -D headset-sco -f s16_le -r 8000 | \
aplay -D headset-sco -f s16_le -r 8000
This should send all input captured right back to the headset, but it doesn't.
The following is debug output from pcm_sco.c:
DEBUG(pid=7780): _snd_pcm_sco_open: Starting pcm_sco_headset plugin.
DEBUG(pid=7780): _snd_pcm_sco_open: Open mode is for Playback.
DEBUG(pid=7780): _snd_pcm_sco_open: do_cfg >>
DEBUG(pid=7780): do_cfg: send (PKT_TYPE_CFG_BDADDR) >>
DEBUG(pid=7780): do_cfg: <<send (PKT_TYPE_CFG_BDADDR)
DEBUG(pid=7780): do_cfg: recv (PKT_TYPE_CFG_BDADDR) >>
DEBUG(pid=7779): _snd_pcm_sco_open: Starting pcm_sco_headset plugin.
DEBUG(pid=7779): _snd_pcm_sco_open: Open mode is for Capture.
DEBUG(pid=7779): _snd_pcm_sco_open: do_cfg >>
DEBUG(pid=7779): do_cfg: send (PKT_TYPE_CFG_BDADDR) >>
DEBUG(pid=7779): do_cfg: <<send (PKT_TYPE_CFG_BDADDR)
DEBUG(pid=7779): do_cfg: recv (PKT_TYPE_CFG_BDADDR) >>
DEBUG(pid=7780): do_cfg: <<recv (PKT_TYPE_CFG_BDADDR)
DEBUG(pid=7780): do_cfg: send (PKT_TYPE_CFG_PAGINGTIMEOUT) >>
DEBUG(pid=7780): do_cfg: <<send (PKT_TYPE_CFG_PAGINGTIMEOUT)
DEBUG(pid=7780): do_cfg: recv (PKT_TYPE_CFG_PAGINGTIMEOUT) >>
DEBUG(pid=7780): do_cfg: <<recv (PKT_TYPE_CFG_PAGINGTIMEOUT)
DEBUG(pid=7780): _snd_pcm_sco_open: << do_cfg, get_sco_fd >>
DEBUG(pid=7780): _snd_pcm_sco_open: << get_sco_fd (OK)
DEBUG(pid=7780): _snd_pcm_sco_open: opened as ioplug=0x805ebd0, pcm=0x805ed08,
ioplug->callback = 0xb7f48f40
Aborted by signal Interrupt...
DEBUG(pid=7780): sco_headset_close: closing ioplug=0x805ebd0
DEBUG(pid=7780): sco_headset_close: Closing Playback stream
(the << and >> messages are print before and after the corresponding function
calls)
Suspicious here is:
1) "opened as ioplug=..." appears only once.
2) this is because do_cfg() only returns for process 7780, but not for 7779
3) which in turn is caused by the recv() call in do_cfg() which is blocking,
waiting for an answer from headsetd about the PKT_TYPE_CFG_BDADDR it sends.
So why is headsetd not processing the config request of the 2nd process?
I'm not sure about the reason for this, but it doesn't get to dispatch the
event that would send the answer pcm_sco.c is waiting for. It's somehow
blocked by the first process. As soon as I kill the arecord/aplay combo, it
gets to process the second CFG_BDADDR packet.
Another test:
$ arecord -D headset-sco -f s16_le -r 8000 > testfile
[testfile is recorded ok, keep arecord running]
$ aplay -D headset-sco -f s16_le -r 8000 < existing-testfile
In this scenario, aplay will be frozen until I kill arecord. Then it plays
back the sound.
So why is headsetd blocking the second application while the first one is
running?
I'd appreciate any hints,
Robert
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
dmix and dsnoop requires hw interrupts. Thats why they are bundled inside
alsa-lib and not in alsa-plugins. If you want to do dmx or dsnoop stuff, you
should definetly have a look at PulseAudio as Brad suggested. Not however
that PulseAudio require NON_BLOCKING alsa pcm. I am unsure about the sco
alsa plugin support for NON_BLOCKING mode. Maybe Brad could comment.
my 2cents,
--
Marc-Andr? Lureau, GSmartMix
On 5/24/07, Brad Midgley <[email protected]> wrote:
>
> Robert
>
> > Could it be that some of the ALSA plugins only work with hardware
> > devices?!
>
>
> that is a real possibility. libalsa plugins are definitely second-class.
>
> i am searching around in headsetd to see if it restricts the mic and
> speaker sockets to be sent to the same application. it should be easy enough
> to keep track of these two independently.
>
> Brad
>
>
>
> -------------------------------------------------------------------------
> 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
> [email protected]<https://mail.google.com/mail?view=cm&tf=0&[email protected]>
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
Robert
> Could it be that some of the ALSA plugins only work with hardware
> devices?!
that is a real possibility. libalsa plugins are definitely second-class.
i am searching around in headsetd to see if it restricts the mic and speaker
sockets to be sent to the same application. it should be easy enough to keep
track of these two independently.
Brad
Brad Midgley wrote:
> *John
>
> *
>
>
> I've been using the a2dpd app for a couple of weeks now, and
> really like
> it. I have a few issues though, with the main one being that after a
> couple of minutes of playback, my headphones (HT820) turn off
>
>
> it looks like alsa_transfer_raw returns -1 once and then a2dpd closes
> the connection. Maybe we should be checking for an error state that
> indicates we can retry or maybe we should retry a few times regardless.
>
> it could be the set turns off because of the way we terminate the
> connection. This is mostly Frederic's playground but I remember
> locking up headsets with a2play by accidentally sending data on the
> stream fd after we had signaled a stream close on the control fd.
>
> brad
Brad, thank you for the reply. To try to understand this, you're saying
that when I get:
a2dp_transfer_raw: Wrote -1 not 603 bytes (sbc.len=118)
transfer_outgoing_packets: Error in transfer (transfer=-1)
The issue could be that the headset is expecting a value of a certain
length, and since the value -1 is not that length, the headset doens't
like that, and shuts down? If this is the case, where should I look to
change that value, and what should it be changed to? I wouldn't mind
sending some dummy data and have it drop out for a second once in a
while, as long as I don't have to keep restarting the thing. At least it
would be a temporary fix.
I found the IF block in a2dpd_output_a2dp.c:
if (a2dp->sk > 0) {
// Pause?
// The value 0 have finally been tested ;)
// However, we may safely simulate a failed write
if (!a2dp->pause_writing) {
// Send our data
if ((written = write(a2dp->sk, a2dp->buf, a2dp->len)) !=
a2dp->len) {
// Error while sending data
DBG("Wrote %d not %d bytes (sbc.len=%d)", written,
a2dp->len, a2dp->sbc.len);
// Return the error
result = written;
}
...
That seems to be the only place that contains that string, that I could
find. I can't find out where the function "write" is defined either.
I'll keep looking, and if you guys can give me some suggestions of
things to try and what I should be looking at, I will and let you all
know how it goes.
Thanks again,
John
John
> I've been using the a2dpd app for a couple of weeks now, and really like
> it. I have a few issues though, with the main one being that after a
> couple of minutes of playback, my headphones (HT820) turn off
>
it looks like alsa_transfer_raw returns -1 once and then a2dpd closes the
connection. Maybe we should be checking for an error state that indicates we
can retry or maybe we should retry a few times regardless.
it could be the set turns off because of the way we terminate the
connection. This is mostly Frederic's playground but I remember locking up
headsets with a2play by accidentally sending data on the stream fd after we
had signaled a stream close on the control fd.
brad
Hello,
I've been using the a2dpd app for a couple of weeks now, and really like
it. I have a few issues though, with the main one being that after a
couple of minutes of playback, my headphones (HT820) turn off, I turn
them back on, and playback continues. I use these things long periods of
time with my iPod and a Jabra a2dp adapter, I can listen for hours on an
a2dp connection with those without interruption (aside from the
occasional phone call). But within a couple of minutes using the a2dpd
app (and amarok or mplayer), the connection gets really choppy, then
drops out, and I have to turn _on_ my headphones. As you might guess,
this is a show stopper for me, as I can't really enjoy listening to
music wirelessly if I can't get through an entire song without turning
my headphones back on.
Any ideas on why this is happening would be helpful, as right now, I
don't even know where to start looking. Here's the output when it fails:
A2DPD[11:10:02.275]: a2dp_transfer_raw: Wrote -1 not 603 bytes (sbc.len=118)
A2DPD[11:10:02.275]: transfer_outgoing_packets: Error in transfer
(transfer=-1)
A2DPD[11:10:02.275]: a2dp_state_disconnect: State
AVDTP_STATEX_STREAM_CLOSING
A2DPD[11:10:02.275]: a2dp_state_machine: State
AVDTP_STATEX_STREAM_CLOSING_WAIT
A2DPD[11:10:02.275]: a2dpd_signal_state: Connecting 00:07:A4:B8:68:8F
A2DPD[11:10:05.005]: a2dp_state_machine: Too many answer for AVDTP_CLOSE
A2DPD[11:10:05.005]: a2dp_state_machine: State AVDTP_STATEX_DISCONNECTING
A2DPD[11:10:05.005]: a2dp_disconnect:
A2DPD[11:10:05.005]: a2dp_stream_stop: Closing stream socket 12
A2DPD[11:10:05.005]: a2dp_stream_stop: Closed
A2DPD[11:10:05.005]: a2dp_stream_stop: State AVDTP_STATE_IDLE
A2DPD[11:10:05.005]: a2dp_disconnect: Closing ctl socket 10
A2DPD[11:10:05.005]: a2dp_disconnect: Closed
A2DPD[11:10:05.005]: a2dp_disconnect: State AVDTP_STATE_DISCONNECTED
A2DPD[11:10:05.005]: a2dpd_signal_state: Disconnected
A2DPD[11:10:05.005]: a2dp_state_connect: State AVDTP_STATEX_SDP_CONNECTING
A2DPD[11:10:05.005]: a2dp_state_machine: Role is INITIATOR
A2DPD[11:10:05.005]: a2dp_state_machine: SDP connection on socket 10
A2DPD[11:10:05.005]: a2dp_state_machine: State
AVDTP_STATEX_SDP_CONNECTING_WAIT
A2DPD[11:10:05.005]: a2dpd_signal_state: Connecting 00:07:A4:B8:68:8F
A2DPD[11:10:11.515]: a2dp_state_machine: SDP connection terminated
A2DPD[11:10:11.515]: a2dp_state_machine: (errno=110:Connection timed
out)SDP connection failed
A2DPD[11:10:11.515]: a2dp_state_machine: State AVDTP_STATEX_DISCONNECTING
A2DPD[11:10:11.515]: a2dp_disconnect:
A2DPD[11:10:11.516]: a2dp_stream_stop: Closing stream socket -1
A2DPD[11:10:11.516]: a2dp_stream_stop: Closed
A2DPD[11:10:11.516]: a2dp_stream_stop: State AVDTP_STATE_IDLE
A2DPD[11:10:11.516]: a2dp_disconnect: Closing ctl socket -1
A2DPD[11:10:11.516]: a2dp_disconnect: Closed
A2DPD[11:10:11.516]: a2dp_disconnect: State AVDTP_STATE_DISCONNECTED
A2DPD[11:10:11.516]: a2dpd_signal_state: Disconnected
A2DPD[11:10:11.523]: a2dp_state_connect: State AVDTP_STATEX_SDP_CONNECTING
A2DPD[11:10:11.524]: a2dp_state_machine: Role is INITIATOR
A2DPD[11:10:11.524]: a2dp_state_machine: SDP connection on socket 10
A2DPD[11:10:11.524]: a2dp_state_machine: State
AVDTP_STATEX_SDP_CONNECTING_WAIT
A2DPD[11:10:11.524]: a2dpd_signal_state: Connecting 00:07:A4:B8:68:8F
Thank you, I appreciate your help,
John
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
On Donnerstag, 17. Mai 2007, Brad Midgley wrote:
> headsetd is written to allow a single application to use the headset at one
> time. it doesn't multiplex the mic or mix to the speaker. one of the two
> apps will fail to get exclusive access. it's basically a latency
> optimization but there's room for something like dmix or a sound server
> like pulse to make it more flexible.
Thanks for pointing that out, not exactly what I wanted to hear, but it's an
explanation ;-)
I played a bit with dmix, dsnoop, dshare etc., but I cannot get any of the d*
plugins to work. The error message is always the same:
-----
$ arecord -D headset-test -f s16_le -r 8000 | aplay -D headset-test -f
s16_le -r 8000
ALSA lib pcm_direct.c:1464:(_snd_pcm_direct_get_slave_ipc_offset) Invalid
type 'sco' for slave PCM
aplay: main:545: audio open error: Invalid argument
ALSA lib pcm_direct.c:1464:(_snd_pcm_direct_get_slave_ipc_offset) Invalid
type 'sco' for slave PCM
arecord: main:545: audio open error: Invalid argument
-----
this is with the following sections in .asoundrc (they might not be exactly
what's needed here, but the same error messages appear as soon as I throw one
of the dmix/dsnoop/... plugins into the chain):
pcm.dmixed {
ipc_key 1025
type dmix
slave.pcm "headset-sco"
}
pcm.dsnooped {
ipc_key 1027
type dsnoop
slave.pcm "headset-sco"
}
pcm.headset-test {
type asym
playback.pcm "dmixed"
capture.pcm "dsnooped"
}
Could it be that some of the ALSA plugins only work with hardware devices?!
Robert
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thursday 17 May 2007 04:42, you wrote:
> Robert
>
> headsetd is written to allow a single application to use the headset
> at one time. it doesn't multiplex the mic or mix to the speaker. one
> of the two apps will fail to get exclusive access. it's basically a
> latency optimization but there's room for something like dmix or a
> sound server like pulse to make it more flexible.
>
> if skype is written such that input and output are separate file
> descriptors obtained through independent open() calls then it will
> also fail, even if they're in the same thread. that may be how it's
> written, especially if they let you choose one device for mic and
> another for speaker.
>
Ah.. I think this is why I could not get the audio to work in both
directions when I tried sparkle (voip client). I ran out of time to
investigate it, but this matches up.
Can we not do something magic with the .asoundrc again to split it into
2 devices essentially? I guess this is the dmix plugin, but I thought
there was something simpler to just split recording and playback. Or is
dsnoop needed?
Cheers,
Tim
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Robert
headsetd is written to allow a single application to use the headset at one
time. it doesn't multiplex the mic or mix to the speaker. one of the two
apps will fail to get exclusive access. it's basically a latency
optimization but there's room for something like dmix or a sound server like
pulse to make it more flexible.
if skype is written such that input and output are separate file descriptors
obtained through independent open() calls then it will also fail, even if
they're in the same thread. that may be how it's written, especially if they
let you choose one device for mic and another for speaker.
Brad
On 5/16/07, Robert Huitl <[email protected]> wrote:
>
>
> So why is headsetd blocking the second application while the first one is
> running?