--- On Tue, 13/7/10, Johan Hedberg <johan.hedberg@xxxxxxxxx> wrote: > From: Johan Hedberg <johan.hedberg@xxxxxxxxx> > Subject: Re: ipc-sock/l2cap sock/g_io_fd > To: "Pavan Savoy" <pavan_savoy@xxxxxxxxxxx> > Cc: linux-bluetooth@xxxxxxxxxxxxxxx, "Marcel Holtmann" <marcel@xxxxxxxxxxxx> > Date: Tuesday, 13 July, 2010, 6:27 PM > Hi Pavan, > > On Tue, Jul 13, 2010, Pavan Savoy wrote: > > Marcel, > > I don't know why you expect specifically Marcel to have > some clue about > the audio stuff. He hasn't been much involved with the > development of it > so I don't excpect you to get a reply from him ;) Isn't Marcel = GOD for bluetooth on linux ? Although I did put it to the list. > > I am sort of lost among the various sockets that are > in the > > bluez/audio, and trying to get a clear picture on what > is what. > > > > find attached the short image on my understanding of > the audio > > structure (currently used by apps which use liba2dp > and not the pcm > > plugins..- namely android..) > > > > Is my understanding correct ? > > What does the various sockets represent, as in > stream.fd, server.fd - > > and the fd extracted from the session_io. > > > > I sort of need to know which is which, as in which is > communication > > over local IPC BT_IPC_SOCKET_NAME, which actually > corresponds to the > > l2cap connection which is established in sink.c ? > > > > How does it get into the sesssion->io ? Please help > me understand > > these various sock fd's. > > So I'd say there are three key sockets with A2DP. You've > got the > signalling channel for A2DP (I think that's what you mean > when you say > session->io). That socket stays always inside > bluetoothd. Then there's a > local unix socket which is used to communicate with an > external audio > process (alsa, gstreamer, pulseaudio, whatever). I suspect > that'd match > the server.fd which you mentioned. Then, for every A2DP > media transport > channel we transfer the socket over to the external audio > process which > then takes care of writing (and reading in the case of SCO) > of it. > That's what stream.fd is referring to. Very nice to know, thanks a lot. > With BlueZ 5.0 we're gonna scrap the unix socket completely > since D-Bus > nowdays has support for file descriptor transfer from one > process to > another. There's already a prototype patch for it but it > hasn't been > merged upstream yet. Hopefully getting rid of the extra > homebrewed IPC > should help simplify the picture a little bit. Yes, So as I understand, the func "bt_audio_service_get_data_fd" helps us pass around the stream fd to another process, which can use it for writing, the CMSG thingy ?? Where exactly is it filled up to do a recvmsg ? As in somewhere I should have found a memcpy(CMSG_DATA, &stream.fd, sizeof(int)) ? Great, fd passing around over D-Bus, This info, solves my other problem too :) Will look it up .. > Johan > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
