yes, a2dp timing is whacked

Maybe for convenience, libsbc should compute the timeslice for the frame.

I will start by looking at the rtc interface and trying to find hooks in alsa for timing.

Quoted 2 lines

Maybe for convenience, libsbc should compute the timeslice for the frame.

It does now. I added a function sbc_time(sbc_t *sbc) which computes the microseconds for one frame. I then replaced the fixed value in a2play's usleep() call with the time the whole packet should take to play (time for one frame times number of frames in the packet) multiplied by (arbitrarily chosen) 0.8 to make up for the time lost with computing and sending.

Quoted 9 lines

Quoted 2 lines

Maybe for convenience, libsbc should compute the timeslice for the frame.

It does now. I added a function sbc_time(sbc_t *sbc) which computes the microseconds for one frame. I then replaced the fixed value in a2play's usleep() call with the time the whole packet should take to play (time for one frame times number of frames in the packet) multiplied by (arbitrarily chosen) 0.8 to make up for the time lost with computing and sending.

the time that is eaten up by encoding or decoding could be measured with gettimeofday() and then you can subtract this from the whole time.

Since it is a linear operation we can make the SBC library do it all for us. Let sbc_encode() and sbc_decode() calculate the processing time and then store a sleep value for us inside sbc_t.

forget about this stupid idea. I tried it and it is not working out.

So the best thing is too encode two or three full AVDTP frames in advance and have them ready to send. The sending can't be controlled be usleep(). We need a time that kicks in every whatever msec and makes us to transmit the next frame.

Quoted 4 lines

So the best thing is too encode two or three full AVDTP frames in advance and have them ready to send. The sending can't be controlled be usleep(). We need a time that kicks in every whatever msec and makes us to transmit the next frame.

That's what I would favour. According to the libc manual setitimer() would be the function of choice, if nobody else has a better idea (RTC, anyone?).

Hi Henryk,

Quoted 8 lines

Quoted 4 lines

So the best thing is too encode two or three full AVDTP frames in advance and have them ready to send. The sending can't be controlled be usleep(). We need a time that kicks in every whatever msec and makes us to transmit the next frame.

That's what I would favour. According to the libc manual setitimer() would be the function of choice, if nobody else has a better idea (RTC, anyone?).

so in general the time that a SBC frame is calculated for, is always the same if we don't change the parameters, right?

Using the ITIMER_REAL domain may works and since you can setup your timer in microseconds, then this would be the way to go.

Guys,

I put a rough proof-of-concept implementation together using setitimer. (Yes, it's gross and the signal handler doesn't actually do any work, just indicates that the interval is over)

The music seems to be timed right but it's a very "noisy" signal on the hp headset. Any ideas?

I didn't commit it because it's so ugly.

Brad

Quoted 15 lines · Marcel Holtmann

Hi Henryk,

Quoted 9 lines

Quoted 4 lines

So the best thing is too encode two or three full AVDTP frames in advance and have them ready to send. The sending can't be controlled be usleep(). We need a time that kicks in every whatever msec and makes us to transmit the next frame.

That's what I would favour. According to the libc manual setitimer() would be the function of choice, if nobody else has a better idea (RTC, anyone?).

Quoted 5 lines

so in general the time that a SBC frame is calculated for, is always the same if we don't change the parameters, right?

Using the ITIMER_REAL domain may works and since you can setup your timer in microseconds, then this would be the way to go.

------------------------------------------------------------------------

Index: a2play.c
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/a2play.c,v retrieving revision 1.64
diff -u -b -B -w -p -r1.64 a2play.c

a2play.c +26 -1

@@ -56,6 +56,7 @@
 #define BUFS 1024
 
 static volatile int terminate = 0;
+static volatile int xmitpause = 0;
 static int cmdfd;
 
 struct sbc_frame_header sbc_info;

@@ -102,6 +103,16 @@ static void sig_term(int sig)
 	terminate = 1;
 }
 
+static void sig_alrm(int sig)
+{
+	struct sigaction sa;
+	memset(&sa, 0, sizeof(sa));
+	sa.sa_flags = SA_NOCLDSTOP;
+	sa.sa_handler = sig_alrm;
+	sigaction(SIGALRM, &sa, NULL);
+	xmitpause = 0;
+}
+
 // Usage
 static void usage()
 {

@@ -404,6 +415,8 @@ s_config was set from sbc_info before:
 
 int main(int argc, char *argv[])
 {
+	int timerset = 0;
+	struct itimerval itimer;
 	struct sigaction sa;
 	struct timeval start, end;
 	int streamfd;

@@ -619,6 +632,8 @@ int main(int argc, char *argv[])
 
 	timestamp = 0;
 
+	sig_alrm(0);
+
 	while (!terminate) {
 
 		// a2dp headers: avdtp p.45

@@ -698,8 +713,18 @@ int main(int argc, char *argv[])
 
 			memcpy(buf + sizeof(packet_header), &payload_header, sizeof(payload_header));
 			write(streamfd, buf, psize);
-			//printf("\nSending packet:%d, size %d no. of sbc frames:%d", seq_num, psize, payload_header.frame_count);
 
+			if(!timerset) {
+				timerset = 1;
+				itimer.it_interval.tv_sec = itimer.it_value.tv_sec = 0;
+				itimer.it_interval.tv_usec = itimer.it_value.tv_usec = (sleeptime*95)/100;
+				if(setitimer(ITIMER_REAL, &itimer, NULL)) printf("couldn't setitimer\n");
+			}
+
+			while(xmitpause) usleep(10);
+			xmitpause = 1;
+#if 0
+			//printf("\nSending packet:%d, size %d no. of sbc frames:%d", seq_num, psize, payload_header.frame_count);
 			pending++;
 
 			if (pending > 4) {

I think my hack introduced timing issues of its own... tomorrow I'll fix it up with code that uses a ring buffer and bleeds from the ring in the sighandler.