Alsa plugin fix

All,

I've spent most of my afternoon fixing the support for my favorite media player, the descendant of XMMS : audacious. :-)

Audacious was almost working except for a *very* annoying bug (in our side :-( ). It would
eventually stop playing at the end of each song, which meant i would have to manually select the next song and hit play again... not very funny :-(

Now it looks it works perfectly (didn't have time to check that in details, but that should be fixed as soon i tomorrow, after i would have spent the most part of the day listening to music with Audacious ;-) )

The patch is fairly simple, it implements the delay() call to make sure we change the pcm state to the XRUN state whenever the hw_ptr moves on top of appl_ptr.

Anybody to review it and commit to CVS ?

Cheers,

Fabien

Index: pcm_bluetooth.c
===================================================================
@@ -764,6 +764,25 @@
 	return ret;
 }
 
+static int bluetooth_playback_delay(snd_pcm_ioplug_t *io, 
+				snd_pcm_sframes_t *delayp)
+{
+	DBG("");
+
+	/* This updates io->hw_ptr value using pointer() function */
+	snd_pcm_hwsync(io->pcm);
+ 	
+	*delayp = io->appl_ptr - io->hw_ptr;
+	if ((io->state == SND_PCM_STATE_RUNNING) && (*delayp < 0)) {
+		io->callback->stop(io);
+		io->state = SND_PCM_STATE_XRUN;
+		*delayp = 0;
+	}
+	/* This should never fail, ALSA API is really not
+	prepared to handle a non zero return value */
+	return 0;
+}
+
 static snd_pcm_ioplug_callback_t bluetooth_hsp_playback = {
 	.start			= bluetooth_playback_start,
 	.stop			= bluetooth_playback_stop,

@@ -774,6 +793,7 @@
 	.transfer		= bluetooth_hsp_write,
 	.poll_descriptors	= bluetooth_playback_poll_descriptors,
 	.poll_revents		= bluetooth_playback_poll_revents,
+	.delay			= bluetooth_playback_delay,
 };
 
 static snd_pcm_ioplug_callback_t bluetooth_hsp_capture = {

@@ -798,6 +818,7 @@
 	.transfer		= bluetooth_a2dp_write,
 	.poll_descriptors	= bluetooth_playback_poll_descriptors,
 	.poll_revents		= bluetooth_playback_poll_revents,
+	.delay			= bluetooth_playback_delay,
 };
 
 static snd_pcm_ioplug_callback_t bluetooth_a2dp_capture = {

Fabien,

I noticed the same problem with xmms, but it works great now. I committed your fix.

thanks
Brad

)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Thanks !

Btw, maybe we should put Audacious on the HOWTO/Audiodevices pages and recommand its usage instead of XMMS/BMP, which both seem to have been abandonned ?

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi,

It doen't hurt to leave xmms in there since it is just a few lines to explain how to
enable its support, we just need to mark it as not recommended and include Audacious as a recommended player along with gstreamer based ones.

btw, great work!

-- =

Luiz Augusto von Dentz
Engenheiro de Computa=E7=E3o

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello Luiz,

I 100% agree with you. :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fabien,

you know that you can edit the wiki by yourself ;)

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello,

I have been working on socket concurrency tests in the last days, i.e. opening RFCOMM sockets to a maximum number of remote devices (mobile phones in this case). I have used a usual "connect" with blocking sockets - socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM). Each connection is performed to a different mobile phone, I have a row of phones on my desk :)

I'm using a 2.6.22.12 kernel with BlueZ 3.20 libs/utils, and from 1 to 4 bluetooth dongles (Bt 2.0 EDR USB 2.0, an USB 2.0 hub connected to an USB 2.0 port). "passkey-agent --default 0000 &" running.

1) With one bluetooth dongle only : I can successfully open up to 7 concurrent connections to 7 mobile phones, then a sleep(60), then close the socket. I simply create one process for each connect() to each device and launch them all as fast as possible. It's working fine except :
- when one mobile host is down (I have intentionally switched one off) then all next "connect" are delayed, and usually lead to a "connection timeout" or "operation now in progress" when leaving the "connect".
- when a pairing is required it is about the same, all the rest seems delayed.

2) With more dongles, trying to perform (still at the same time) a connect() to one phone on hci0, another on hci1 etc ... up to hci3 (i.e. only 4 connects to 4 devices), I always get connections errors, and the first connection try seems to get a lot of time.

I will certainly come back tomorrow with some hcidumps, but basically I have the feeling that some operations are blocking, and I also wonder about the blocking connect() timeout, which sometimes makes connect() exit with a E_INPROGRESS or a connection timeout -in my opinion- a bit too quickly.

If someone could help me in my investigations it would be really great !!

Best regards,
Oli

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel,

Sure, just wanted to make sure you guys would agree before to make the changes :-)

Cheers,

Fabien

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel