I debugged a bit further <div class="gmail_quote">2010/1/2 Burkhard Stubert <<a href="mailto:burkhard.stubert@googlemail.com">burkhard.stubert@googlemail.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi Tanu, Thanks for the detailed analysis and for pointing out the reincarnation of the pulseaudio process. In the meantime, I succeeded in running scenario with pulseaudio v0.9.21. The result is exactly the same. It fails on the same assertion, pulseaudio dies and restarts after about 30 seconds. It looks very much like a bug report. I had a closer look at the log just before the failed assertion (some lines before tag ###1). Pulseaudio tells bluetoothd to set the configuration as follows: Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: Sending BT_REQUEST -> BT_SET_CONFIGURATION Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: Trying to receive message from audio service... Dec 31 16:01:11 beee bluetoothd[956]: Audio API: BT_REQUEST <- BT_SET_CONFIGURATION Dec 31 16:01:11 beee bluetoothd[956]: Media Codec: SBC Channel Modes: JointStereo Frequencies: 48Khz Subbands: 8 Blocks: 16 Bitpool: 2-51 Immediately before tag ###1, pulseaudio shows the configuration it has actually set: Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: SBC parameters: Dec 31 16:01:11 beee bluetoothd[956]: setup_free(0x2a8f010) Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: #011allocation=0 Dec 31 16:01:11 beee bluetoothd[956]: avdtp_unref(0x2a84940): ref=3 Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: #011subbands=1 Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: #011blocks=3 Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: #011bitpool=51 Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: Connection to the device configured Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: Got the stream socket This looks very suspicious to me. Bluetoothd sends "8 subbands" and "16 blocks" back to pulseaudio, but pulseaudio receives "1 subband" and "3 blocks". That looks wrong, doesn't it? </blockquote><div>The discrepancy above might not be the real problem. Things are just encoded in a different way: 16 blocks are encoded as 0x03 and 8 subbands as 0x01. But, in sbc_get_frame_length() the encoding is decoded again. And now it's getting interesting. According to the assertion, sbc_get_frame_length() computes a frame length that is different from the actually received length in the packet. In the assertion, decoded == 109 and frame_length == 115. On top of it, the assertion fires the first time the execution runs over it. So, the assertion is never satisfied. Something is really wrong here. But what? Burkhard </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="gmail_quote">2010/1/2 Tanu Kaskinen <<a href="mailto:tanuk@iki.fi" target="_blank">tanuk@iki.fi</a>><div> <div></div><div class="h5"> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> pe, 2010-01-01 kello 16:02 +0100, Burkhard Stubert kirjoitti: <div>> Hi chaps, > > A happy new year to you all. > > I want to turn my Ubuntu-Karmic-based eee-PC into a Bluetooth stereo > headset (eventually, the eee will be replaced by a car infotainment > system). The eee connects via Bluetooth to a mobile phone, which acts > as an audio source for the eee. The music played on the mobile is > transported via Bluetooth to the eee and comes out of the eee's > speakers. That's the theory. In practise, the streaming stops after > 3-5 seconds and there is no sound any way. > > From the syslog messages (see attachment playmusic3.syslog), I see the > following: > * At tag "###1", pulseaudio has successfully created an audio > source "bluez_source.00_25_48_F5_D8_15". > * At tag "###2", the audio stream seems to be set up correctly. > The message is "module-bluetooth-device.c: Stream properly set > up, we're ready to roll!". > * At tag "###3", there are some problems setting rlimit's. I > guess because pulseaudio runs in a per-user session and does > not have the access privileges to change the rlimit's. I > assume that the problem isn't really important. </div>Correctly assumed. > * From tag "###4" to tag "###5", pulseaudio tells alsa-mixer to <div>> look at profiles. It actually finds three supported profiles: > ###4a - output:analog-stereo, ###4b - output:analog-stereo > +input:analog-stereo, ###4c - input:analog-stereo. Question: > What are these ALSA profiles used for? </div>They are for switching the mode in which the sound card is used. Your card can be used in three modes: analog stereo out, analog stereo in, and a combination of them. There could be more on some other sound card; I think the main motivation for the profiles came from the desire to switch between stereo and surround modes. > * At tag "###6", things seem to go wrong with the message <div>> "alsa-mixer.c: Unable to attach to mixer front:0: No such file > or directory". But maybe this problem can be ignored, because > the next line says "alsa-mixer.c: Successfully attached to > mixer 'hw:0'". </div>Yes, it can be ignored. The alsa mixer apparently can't be opened using the "front" device. I'm not sure if this is a bug in the driver, but we can use "hw" as well. > * At tag "###7", pulseaudio seems to fall back to some default <div>> sinks and sources (module-device-restore.c comes into play). > That doesn't look good. Question: What's going wrong here? </div>Nothing is wrong. When sinks and sources are loaded, module-device-restore restores them to the same state that they had when pulseaudio was previously running. > * At tag "###8", things start to repeat and it is the same steps <div>> and message as from tag "###1". > Any ideas what is going wrong in my setup? </div>There are crashes, so apparently nothing is wrong in the setup. The a2dp source is just buggy. Here are notes about each pulseaudio pid change: The log sample starts with some bluetooth activity, apparently the a2dp source is being loaded. Pulseaudio has pid 1518. After ###2 the bluetooth device module fails an assertion: Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: Assertion '(size_t) decoded == a2dp->frame_length' failed at modules/bluetooth/module-bluetooth-device.c:1367, function a2dp_process_push(). Aborting. A new pulseaudio process is spawned with pid 1772. Here's a mystery: Dec 31 16:01:12 beee pulseaudio[1772]: card.c: Created 1 "bluez_card.00_25_48_F5_D8_15" Dec 31 16:01:43 beee pulseaudio[2030]: module-bluetooth-device.c: Connected to the bluetooth audio service What's happening here? During 31 seconds pulseaudio pid changes from 1772 to 2030, but nothing is logged during this change. Then the same assertion failure occurs again: Dec 31 16:01:43 beee pulseaudio[2030]: module-bluetooth-device.c: Assertion '(size_t) decoded == a2dp->frame_length' failed at modules/bluetooth/module-bluetooth-device.c:1367, function a2dp_process_push(). Aborting. After that a new pulseaudio instance is spawned with pid 2060. That stays running until the end of the log sample. You seem to be running pulseaudio 0.9.19. There were some bluetooth fixes in 0.9.20; I recommend updating to 0.9.21. If the bugs are still there, file a new ticket. -- Tanu Kaskinen _______________________________________________ pulseaudio-discuss mailing list <a href="mailto:pulseaudio-discuss@mail.0pointer.de" target="_blank">pulseaudio-discuss@mail.0pointer.de</a> <a href="https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss" target="_blank">https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss</a> </blockquote></div></div></div> </blockquote></div>