I debugged a bit further 2010/1/2 Burkhard Stubert <burkhard.stubert at googlemail.com> > 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: #011* > subbands=1* > Dec 31 16:01:11 beee pulseaudio[1518]: module-bluetooth-device.c: #011* > blocks=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? > > 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 > > 2010/1/2 Tanu Kaskinen <tanuk at iki.fi> > > pe, 2010-01-01 kello 16:02 +0100, Burkhard Stubert kirjoitti: >> > 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. >> >> Correctly assumed. >> >> > * From tag "###4" to tag "###5", pulseaudio tells alsa-mixer to >> > 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? >> >> 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 >> > "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'". >> >> 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 >> > sinks and sources (module-device-restore.c comes into play). >> > That doesn't look good. Question: What's going wrong here? >> >> 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 >> > and message as from tag "###1". >> > Any ideas what is going wrong in my setup? >> >> 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 >> pulseaudio-discuss at mail.0pointer.de >> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100102/b0386e91/attachment.htm>
