Hi all,
I use 5506 for USB audio stream to PC in asynchronous isochronous mode.
I hear audio stuttering. While PC request audio every 1 ms via USB
based on PC's clock, 55x process a packet of audio samples every 1 ms
based on DSP's clock. In theory if those two clock match perfectly,
there is no problem. But in reality that DSP clock is slightly
different to PC's, the audio dropps packets here or there about every 1
second. I know there must be a way to solve this problem since I've
seems device working on asynchronous ISO mode. Can anybody shed some
light on this issue?
Thanks,
Wei
USB audio stream with 55x
Started by ●August 24, 2007
Reply by ●August 24, 20072007-08-24
Li Wei-
> I use 5506 for USB audio stream to PC in asynchronous isochronous mode.
> I hear audio stuttering. While PC request audio every 1 ms via USB
> based on PC's clock, 55x process a packet of audio samples every 1 ms
> based on DSP's clock. In theory if those two clock match perfectly,
> there is no problem. But in reality that DSP clock is slightly
> different to PC's, the audio dropps packets here or there about every 1
> second. I know there must be a way to solve this problem since I've
> seems device working on asynchronous ISO mode. Can anybody shed some
> light on this issue?
You can try a technique called software PLL. The idea is that you monitor the drift
between the 2 sampling clocks and subtract/add an audio sample from time-to-time when
the drift exceeds a certain threshold, say 1/4 of the clock period. Basically you
can increment the audio buffer twice at some point (duplicate a sample) or not
increment it (skip one). The adjustment happens so infrequently you're not going to
have noticeable error.
In your case, adjusting samples on the audio side should be straightforward, but on
the host/USB side your DSP code only sees a 1 msec clock, not the sample clock, so
it's more difficult. What is the sampling rate; i.e. how many samples in 1 msec? 8
?
-Jeff
> I use 5506 for USB audio stream to PC in asynchronous isochronous mode.
> I hear audio stuttering. While PC request audio every 1 ms via USB
> based on PC's clock, 55x process a packet of audio samples every 1 ms
> based on DSP's clock. In theory if those two clock match perfectly,
> there is no problem. But in reality that DSP clock is slightly
> different to PC's, the audio dropps packets here or there about every 1
> second. I know there must be a way to solve this problem since I've
> seems device working on asynchronous ISO mode. Can anybody shed some
> light on this issue?
You can try a technique called software PLL. The idea is that you monitor the drift
between the 2 sampling clocks and subtract/add an audio sample from time-to-time when
the drift exceeds a certain threshold, say 1/4 of the clock period. Basically you
can increment the audio buffer twice at some point (duplicate a sample) or not
increment it (skip one). The adjustment happens so infrequently you're not going to
have noticeable error.
In your case, adjusting samples on the audio side should be straightforward, but on
the host/USB side your DSP code only sees a 1 msec clock, not the sample clock, so
it's more difficult. What is the sampling rate; i.e. how many samples in 1 msec? 8
?
-Jeff
Reply by ●August 27, 20072007-08-27
Thanks to Jeff and Aram for the reply.
Pseudo Software PLL and longer buffer seem workable. BTW, fs is 16
KHz. I'll report the result once I have it.
Wei
--- In c..., Jeff Brower wrote:
>
> Li Wei-
>
> > I use 5506 for USB audio stream to PC in asynchronous isochronous
mode.
> > I hear audio stuttering. While PC request audio every 1 ms via USB
> > based on PC's clock, 55x process a packet of audio samples every
1 ms
> > based on DSP's clock. In theory if those two clock match
perfectly,
> > there is no problem. But in reality that DSP clock is slightly
> > different to PC's, the audio dropps packets here or there about
every 1
> > second. I know there must be a way to solve this problem since
I've
> > seems device working on asynchronous ISO mode. Can anybody shed
some
> > light on this issue?
>
> You can try a technique called software PLL. The idea is that you
monitor the drift
> between the 2 sampling clocks and subtract/add an audio sample from
time-to-time when
> the drift exceeds a certain threshold, say 1/4 of the clock
period. Basically you
> can increment the audio buffer twice at some point (duplicate a
sample) or not
> increment it (skip one). The adjustment happens so infrequently
you're not going to
> have noticeable error.
>
> In your case, adjusting samples on the audio side should be
straightforward, but on
> the host/USB side your DSP code only sees a 1 msec clock, not the
sample clock, so
> it's more difficult. What is the sampling rate; i.e. how many
samples in 1 msec? 8
> ?
>
> -Jeff
>
Pseudo Software PLL and longer buffer seem workable. BTW, fs is 16
KHz. I'll report the result once I have it.
Wei
--- In c..., Jeff Brower wrote:
>
> Li Wei-
>
> > I use 5506 for USB audio stream to PC in asynchronous isochronous
mode.
> > I hear audio stuttering. While PC request audio every 1 ms via USB
> > based on PC's clock, 55x process a packet of audio samples every
1 ms
> > based on DSP's clock. In theory if those two clock match
perfectly,
> > there is no problem. But in reality that DSP clock is slightly
> > different to PC's, the audio dropps packets here or there about
every 1
> > second. I know there must be a way to solve this problem since
I've
> > seems device working on asynchronous ISO mode. Can anybody shed
some
> > light on this issue?
>
> You can try a technique called software PLL. The idea is that you
monitor the drift
> between the 2 sampling clocks and subtract/add an audio sample from
time-to-time when
> the drift exceeds a certain threshold, say 1/4 of the clock
period. Basically you
> can increment the audio buffer twice at some point (duplicate a
sample) or not
> increment it (skip one). The adjustment happens so infrequently
you're not going to
> have noticeable error.
>
> In your case, adjusting samples on the audio side should be
straightforward, but on
> the host/USB side your DSP code only sees a 1 msec clock, not the
sample clock, so
> it's more difficult. What is the sampling rate; i.e. how many
samples in 1 msec? 8
> ?
>
> -Jeff
>
Reply by ●August 30, 20072007-08-30
I made a circular buffer of 20ms and inplemented sort of software pll
(duplicating or dropping a sample). The statistics shows I dropped 1
sample per 500 samples or so. Is that too much?
I am thinking dynamic adding or subtracting CLKDIV of McBsp instead of
dropping samples. But TI warned me not to change it on flying. Anyone
has done that? I know you can do it during bootload.
Although I can get statistics by run data stream and they all look
fine, the audio still sounds terrible. I cannot say the method work yet.
Wei
(duplicating or dropping a sample). The statistics shows I dropped 1
sample per 500 samples or so. Is that too much?
I am thinking dynamic adding or subtracting CLKDIV of McBsp instead of
dropping samples. But TI warned me not to change it on flying. Anyone
has done that? I know you can do it during bootload.
Although I can get statistics by run data stream and they all look
fine, the audio still sounds terrible. I cannot say the method work yet.
Wei
Reply by ●August 30, 20072007-08-30
Li Wei-
> I made a circular buffer of 20ms and inplemented sort of software pll
> (duplicating or dropping a sample). The statistics shows I dropped 1
> sample per 500 samples or so. Is that too much?
I suggest to modify your code to output a GPIO pulse each time the code drops/adds a
sample, and watch the pulse and both clocks on a dig scope. When you see the pulse
you should see the clock relationship you expect; i.e. about to "cross over" the
threshold you established for clock drift. If you don't see this, then the algorithm
is not correctly implemented.
I think you said your sampling rate is 16 kHz, so 500 samples is about 30 msec.
That's about a 3% drift between clocks... even if one was 1.5% slow and one was 1.5%
fast, I don't think they should be drifting that much if they are truly based on
accurate, reliable sources.
-Jeff
> I am thinking dynamic adding or subtracting CLKDIV of McBsp instead of
> dropping samples. But TI warned me not to change it on flying. Anyone
> has done that? I know you can do it during bootload.
>
> Although I can get statistics by run data stream and they all look
> fine, the audio still sounds terrible. I cannot say the method work yet.
>
> Wei
> I made a circular buffer of 20ms and inplemented sort of software pll
> (duplicating or dropping a sample). The statistics shows I dropped 1
> sample per 500 samples or so. Is that too much?
I suggest to modify your code to output a GPIO pulse each time the code drops/adds a
sample, and watch the pulse and both clocks on a dig scope. When you see the pulse
you should see the clock relationship you expect; i.e. about to "cross over" the
threshold you established for clock drift. If you don't see this, then the algorithm
is not correctly implemented.
I think you said your sampling rate is 16 kHz, so 500 samples is about 30 msec.
That's about a 3% drift between clocks... even if one was 1.5% slow and one was 1.5%
fast, I don't think they should be drifting that much if they are truly based on
accurate, reliable sources.
-Jeff
> I am thinking dynamic adding or subtracting CLKDIV of McBsp instead of
> dropping samples. But TI warned me not to change it on flying. Anyone
> has done that? I know you can do it during bootload.
>
> Although I can get statistics by run data stream and they all look
> fine, the audio still sounds terrible. I cannot say the method work yet.
>
> Wei
Reply by ●August 30, 20072007-08-30
Most VOIP implementations drop or duplicate a whole
packet instead of samples. Instead of working in
samples try working in 10 millisecond packets. That
would be 160 samples at your 16 KHZ sampling rate.
Since you are dropping 1 in 500 samples, this means
that 16000/500 = 32 samples would be thrown away or
duplicated every second. Therefore you would throw
away or duplicate one packet of 160 samples every
160/32 = 5 seconds. This should not be noticable at
all.
If the audio still sounds bad then you have some other
issue at the audio generation point.
Aram
--- iewil2000 wrote:
> I made a circular buffer of 20ms and inplemented
> sort of software pll
> (duplicating or dropping a sample). The statistics
> shows I dropped 1
> sample per 500 samples or so. Is that too much?
>
> I am thinking dynamic adding or subtracting CLKDIV
> of McBsp instead of
> dropping samples. But TI warned me not to change it
> on flying. Anyone
> has done that? I know you can do it during bootload.
>
> Although I can get statistics by run data stream and
> they all look
> fine, the audio still sounds terrible. I cannot say
> the method work yet.
>
> Wei
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
packet instead of samples. Instead of working in
samples try working in 10 millisecond packets. That
would be 160 samples at your 16 KHZ sampling rate.
Since you are dropping 1 in 500 samples, this means
that 16000/500 = 32 samples would be thrown away or
duplicated every second. Therefore you would throw
away or duplicate one packet of 160 samples every
160/32 = 5 seconds. This should not be noticable at
all.
If the audio still sounds bad then you have some other
issue at the audio generation point.
Aram
--- iewil2000 wrote:
> I made a circular buffer of 20ms and inplemented
> sort of software pll
> (duplicating or dropping a sample). The statistics
> shows I dropped 1
> sample per 500 samples or so. Is that too much?
>
> I am thinking dynamic adding or subtracting CLKDIV
> of McBsp instead of
> dropping samples. But TI warned me not to change it
> on flying. Anyone
> has done that? I know you can do it during bootload.
>
> Although I can get statistics by run data stream and
> they all look
> fine, the audio still sounds terrible. I cannot say
> the method work yet.
>
> Wei
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
Reply by ●September 4, 20072007-09-04
Jeff and Aram,
I had two GPIO to monitor the ISR on scope. Those two ISR should be
quite periodic, every 1ms for USB and every 10ms for DMA. But I did
see missed ISR sometimes. Here I have question: does the USB HWI
preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP one
day workshop' says it doesn't if a dispatcher isn't used. I am not
using BIOS/DSP. I do see USB HWI has higher priority that DMA in
datasheet.
Longer buffer is also been used: 10ms buffer for audio processing and
I am adding or dropping 1ms buffer instead of samples. It sounds
still noisy. Now I am suspicous ISR scheduling as aforemetioned.
Is there any literature states the benifit of working with longer
buffer instead of with samples? VOIP has to deal with 10ms packets
since it drop packets, not samples. But I am an option to work with
samples.
Thanks,
Wei
--- In c..., aram vartanian wrote:
>
> Most VOIP implementations drop or duplicate a whole
> packet instead of samples. Instead of working in
> samples try working in 10 millisecond packets. That
> would be 160 samples at your 16 KHZ sampling rate.
>
> Since you are dropping 1 in 500 samples, this means
> that 16000/500 = 32 samples would be thrown away or
> duplicated every second. Therefore you would throw
> away or duplicate one packet of 160 samples every
> 160/32 = 5 seconds. This should not be noticable at
> all.
>
> If the audio still sounds bad then you have some other
> issue at the audio generation point.
>
> Aram
> --- iewil2000 wrote:
>
> > I made a circular buffer of 20ms and inplemented
> > sort of software pll
> > (duplicating or dropping a sample). The statistics
> > shows I dropped 1
> > sample per 500 samples or so. Is that too much?
> >
> > I am thinking dynamic adding or subtracting CLKDIV
> > of McBsp instead of
> > dropping samples. But TI warned me not to change it
> > on flying. Anyone
> > has done that? I know you can do it during bootload.
> >
> > Although I can get statistics by run data stream and
> > they all look
> > fine, the audio still sounds terrible. I cannot say
> > the method work yet.
> >
> > Wei
> >
> >
>
______________________________________________________________________
______________
> Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos & more.
> http://mobile.yahoo.com/go?refer=1GNXIC
>
I had two GPIO to monitor the ISR on scope. Those two ISR should be
quite periodic, every 1ms for USB and every 10ms for DMA. But I did
see missed ISR sometimes. Here I have question: does the USB HWI
preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP one
day workshop' says it doesn't if a dispatcher isn't used. I am not
using BIOS/DSP. I do see USB HWI has higher priority that DMA in
datasheet.
Longer buffer is also been used: 10ms buffer for audio processing and
I am adding or dropping 1ms buffer instead of samples. It sounds
still noisy. Now I am suspicous ISR scheduling as aforemetioned.
Is there any literature states the benifit of working with longer
buffer instead of with samples? VOIP has to deal with 10ms packets
since it drop packets, not samples. But I am an option to work with
samples.
Thanks,
Wei
--- In c..., aram vartanian wrote:
>
> Most VOIP implementations drop or duplicate a whole
> packet instead of samples. Instead of working in
> samples try working in 10 millisecond packets. That
> would be 160 samples at your 16 KHZ sampling rate.
>
> Since you are dropping 1 in 500 samples, this means
> that 16000/500 = 32 samples would be thrown away or
> duplicated every second. Therefore you would throw
> away or duplicate one packet of 160 samples every
> 160/32 = 5 seconds. This should not be noticable at
> all.
>
> If the audio still sounds bad then you have some other
> issue at the audio generation point.
>
> Aram
> --- iewil2000 wrote:
>
> > I made a circular buffer of 20ms and inplemented
> > sort of software pll
> > (duplicating or dropping a sample). The statistics
> > shows I dropped 1
> > sample per 500 samples or so. Is that too much?
> >
> > I am thinking dynamic adding or subtracting CLKDIV
> > of McBsp instead of
> > dropping samples. But TI warned me not to change it
> > on flying. Anyone
> > has done that? I know you can do it during bootload.
> >
> > Although I can get statistics by run data stream and
> > they all look
> > fine, the audio still sounds terrible. I cannot say
> > the method work yet.
> >
> > Wei
> >
> >
>
______________________________________________________________________
______________
> Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
mail, news, photos & more.
> http://mobile.yahoo.com/go?refer=1GNXIC
>
Reply by ●September 4, 20072007-09-04
Li Wei-
> I had two GPIO to monitor the ISR on scope. Those two ISR should be
> quite periodic, every 1ms for USB and every 10ms for DMA. But I did
> see missed ISR sometimes. Here I have question: does the USB HWI
> preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP one
> day workshop' says it doesn't if a dispatcher isn't used. I am not
> using BIOS/DSP. I do see USB HWI has higher priority that DMA in
> datasheet.
>
> Longer buffer is also been used: 10ms buffer for audio processing and
> I am adding or dropping 1ms buffer instead of samples. It sounds
> still noisy. Now I am suspicous ISR scheduling as aforemetioned.
>
> Is there any literature states the benifit of working with longer
> buffer instead of with samples? VOIP has to deal with 10ms packets
> since it drop packets, not samples. But I am an option to work with
> samples.
My suggestion is to focus on the "missed ISRs" first. I/O has to be reliable and
100% solid before you worry about other things.
How do you know an ISR is missed? One out of, say 100, ISRs would be very difficult
to see on a dig scope, so I'm wondering how you're detecting this.
-Jeff
> --- In c..., aram vartanian wrote:
> >
> > Most VOIP implementations drop or duplicate a whole
> > packet instead of samples. Instead of working in
> > samples try working in 10 millisecond packets. That
> > would be 160 samples at your 16 KHZ sampling rate.
> >
> > Since you are dropping 1 in 500 samples, this means
> > that 16000/500 = 32 samples would be thrown away or
> > duplicated every second. Therefore you would throw
> > away or duplicate one packet of 160 samples every
> > 160/32 = 5 seconds. This should not be noticable at
> > all.
> >
> > If the audio still sounds bad then you have some other
> > issue at the audio generation point.
> >
> > Aram
> > --- iewil2000 wrote:
> >
> > > I made a circular buffer of 20ms and inplemented
> > > sort of software pll
> > > (duplicating or dropping a sample). The statistics
> > > shows I dropped 1
> > > sample per 500 samples or so. Is that too much?
> > >
> > > I am thinking dynamic adding or subtracting CLKDIV
> > > of McBsp instead of
> > > dropping samples. But TI warned me not to change it
> > > on flying. Anyone
> > > has done that? I know you can do it during bootload.
> > >
> > > Although I can get statistics by run data stream and
> > > they all look
> > > fine, the audio still sounds terrible. I cannot say
> > > the method work yet.
> > >
> > > Wei
> > >
> > >
> >
> >
> >
> >
> >
> ______________________________________________________________________
> ______________
> > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
> mail, news, photos & more.
> > http://mobile.yahoo.com/go?refer=1GNXIC
>
> I had two GPIO to monitor the ISR on scope. Those two ISR should be
> quite periodic, every 1ms for USB and every 10ms for DMA. But I did
> see missed ISR sometimes. Here I have question: does the USB HWI
> preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP one
> day workshop' says it doesn't if a dispatcher isn't used. I am not
> using BIOS/DSP. I do see USB HWI has higher priority that DMA in
> datasheet.
>
> Longer buffer is also been used: 10ms buffer for audio processing and
> I am adding or dropping 1ms buffer instead of samples. It sounds
> still noisy. Now I am suspicous ISR scheduling as aforemetioned.
>
> Is there any literature states the benifit of working with longer
> buffer instead of with samples? VOIP has to deal with 10ms packets
> since it drop packets, not samples. But I am an option to work with
> samples.
My suggestion is to focus on the "missed ISRs" first. I/O has to be reliable and
100% solid before you worry about other things.
How do you know an ISR is missed? One out of, say 100, ISRs would be very difficult
to see on a dig scope, so I'm wondering how you're detecting this.
-Jeff
> --- In c..., aram vartanian wrote:
> >
> > Most VOIP implementations drop or duplicate a whole
> > packet instead of samples. Instead of working in
> > samples try working in 10 millisecond packets. That
> > would be 160 samples at your 16 KHZ sampling rate.
> >
> > Since you are dropping 1 in 500 samples, this means
> > that 16000/500 = 32 samples would be thrown away or
> > duplicated every second. Therefore you would throw
> > away or duplicate one packet of 160 samples every
> > 160/32 = 5 seconds. This should not be noticable at
> > all.
> >
> > If the audio still sounds bad then you have some other
> > issue at the audio generation point.
> >
> > Aram
> > --- iewil2000 wrote:
> >
> > > I made a circular buffer of 20ms and inplemented
> > > sort of software pll
> > > (duplicating or dropping a sample). The statistics
> > > shows I dropped 1
> > > sample per 500 samples or so. Is that too much?
> > >
> > > I am thinking dynamic adding or subtracting CLKDIV
> > > of McBsp instead of
> > > dropping samples. But TI warned me not to change it
> > > on flying. Anyone
> > > has done that? I know you can do it during bootload.
> > >
> > > Although I can get statistics by run data stream and
> > > they all look
> > > fine, the audio still sounds terrible. I cannot say
> > > the method work yet.
> > >
> > > Wei
> > >
> > >
> >
> >
> >
> >
> >
> ______________________________________________________________________
> ______________
> > Take the Internet to Go: Yahoo!Go puts the Internet in your pocket:
> mail, news, photos & more.
> > http://mobile.yahoo.com/go?refer=1GNXIC
>
Reply by ●September 12, 20072007-09-12
I use nested HWI to get back the missing ISR now. The software pll is
also working, audio stream is clean.
I saw missing ISR on scope because I missed far more that 1%. I think
deeper memory will help.
Thanks,
Wei
--- In c..., Jeff Brower wrote:
>
> Li Wei-
>
> > I had two GPIO to monitor the ISR on scope. Those two ISR should
be
> > quite periodic, every 1ms for USB and every 10ms for DMA. But I
did
> > see missed ISR sometimes. Here I have question: does the USB HWI
> > preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP
one
> > day workshop' says it doesn't if a dispatcher isn't used. I am not
> > using BIOS/DSP. I do see USB HWI has higher priority that DMA in
> > datasheet.
> >
> > Longer buffer is also been used: 10ms buffer for audio processing
and
> > I am adding or dropping 1ms buffer instead of samples. It sounds
> > still noisy. Now I am suspicous ISR scheduling as aforemetioned.
> >
> > Is there any literature states the benifit of working with longer
> > buffer instead of with samples? VOIP has to deal with 10ms packets
> > since it drop packets, not samples. But I am an option to work
with
> > samples.
>
> My suggestion is to focus on the "missed ISRs" first. I/O has to
be reliable and
> 100% solid before you worry about other things.
>
> How do you know an ISR is missed? One out of, say 100, ISRs would
be very difficult
> to see on a dig scope, so I'm wondering how you're detecting this.
>
> -Jeff
>
> > --- In c..., aram vartanian wrote:
> > >
> > > Most VOIP implementations drop or duplicate a whole
> > > packet instead of samples. Instead of working in
> > > samples try working in 10 millisecond packets. That
> > > would be 160 samples at your 16 KHZ sampling rate.
> > >
> > > Since you are dropping 1 in 500 samples, this means
> > > that 16000/500 = 32 samples would be thrown away or
> > > duplicated every second. Therefore you would throw
> > > away or duplicate one packet of 160 samples every
> > > 160/32 = 5 seconds. This should not be noticable at
> > > all.
> > >
> > > If the audio still sounds bad then you have some other
> > > issue at the audio generation point.
> > >
> > > Aram
> > > --- iewil2000 wrote:
> > >
> > > > I made a circular buffer of 20ms and inplemented
> > > > sort of software pll
> > > > (duplicating or dropping a sample). The statistics
> > > > shows I dropped 1
> > > > sample per 500 samples or so. Is that too much?
> > > >
> > > > I am thinking dynamic adding or subtracting CLKDIV
> > > > of McBsp instead of
> > > > dropping samples. But TI warned me not to change it
> > > > on flying. Anyone
> > > > has done that? I know you can do it during bootload.
> > > >
> > > > Although I can get statistics by run data stream and
> > > > they all look
> > > > fine, the audio still sounds terrible. I cannot say
> > > > the method work yet.
> > > >
> > > > Wei
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
also working, audio stream is clean.
I saw missing ISR on scope because I missed far more that 1%. I think
deeper memory will help.
Thanks,
Wei
--- In c..., Jeff Brower wrote:
>
> Li Wei-
>
> > I had two GPIO to monitor the ISR on scope. Those two ISR should
be
> > quite periodic, every 1ms for USB and every 10ms for DMA. But I
did
> > see missed ISR sometimes. Here I have question: does the USB HWI
> > preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP
one
> > day workshop' says it doesn't if a dispatcher isn't used. I am not
> > using BIOS/DSP. I do see USB HWI has higher priority that DMA in
> > datasheet.
> >
> > Longer buffer is also been used: 10ms buffer for audio processing
and
> > I am adding or dropping 1ms buffer instead of samples. It sounds
> > still noisy. Now I am suspicous ISR scheduling as aforemetioned.
> >
> > Is there any literature states the benifit of working with longer
> > buffer instead of with samples? VOIP has to deal with 10ms packets
> > since it drop packets, not samples. But I am an option to work
with
> > samples.
>
> My suggestion is to focus on the "missed ISRs" first. I/O has to
be reliable and
> 100% solid before you worry about other things.
>
> How do you know an ISR is missed? One out of, say 100, ISRs would
be very difficult
> to see on a dig scope, so I'm wondering how you're detecting this.
>
> -Jeff
>
> > --- In c..., aram vartanian wrote:
> > >
> > > Most VOIP implementations drop or duplicate a whole
> > > packet instead of samples. Instead of working in
> > > samples try working in 10 millisecond packets. That
> > > would be 160 samples at your 16 KHZ sampling rate.
> > >
> > > Since you are dropping 1 in 500 samples, this means
> > > that 16000/500 = 32 samples would be thrown away or
> > > duplicated every second. Therefore you would throw
> > > away or duplicate one packet of 160 samples every
> > > 160/32 = 5 seconds. This should not be noticable at
> > > all.
> > >
> > > If the audio still sounds bad then you have some other
> > > issue at the audio generation point.
> > >
> > > Aram
> > > --- iewil2000 wrote:
> > >
> > > > I made a circular buffer of 20ms and inplemented
> > > > sort of software pll
> > > > (duplicating or dropping a sample). The statistics
> > > > shows I dropped 1
> > > > sample per 500 samples or so. Is that too much?
> > > >
> > > > I am thinking dynamic adding or subtracting CLKDIV
> > > > of McBsp instead of
> > > > dropping samples. But TI warned me not to change it
> > > > on flying. Anyone
> > > > has done that? I know you can do it during bootload.
> > > >
> > > > Although I can get statistics by run data stream and
> > > > they all look
> > > > fine, the audio still sounds terrible. I cannot say
> > > > the method work yet.
> > > >
> > > > Wei
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
Reply by ●September 12, 20072007-09-12
Wei Li-
> I use nested HWI to get back the missing ISR now. The software pll is
> also working, audio stream is clean.
>
> I saw missing ISR on scope because I missed far more that 1%. I think
> deeper memory will help.
Ok, that's great, good work. Do you still have trouble to match audio and packet
clock domains?
-Jeff
> --- In c..., Jeff Brower wrote:
> >
> > Li Wei-
> >
> > > I had two GPIO to monitor the ISR on scope. Those two ISR should
> be
> > > quite periodic, every 1ms for USB and every 10ms for DMA. But I
> did
> > > see missed ISR sometimes. Here I have question: does the USB HWI
> > > preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP
> one
> > > day workshop' says it doesn't if a dispatcher isn't used. I am not
> > > using BIOS/DSP. I do see USB HWI has higher priority that DMA in
> > > datasheet.
> > >
> > > Longer buffer is also been used: 10ms buffer for audio processing
> and
> > > I am adding or dropping 1ms buffer instead of samples. It sounds
> > > still noisy. Now I am suspicous ISR scheduling as aforemetioned.
> > >
> > > Is there any literature states the benifit of working with longer
> > > buffer instead of with samples? VOIP has to deal with 10ms packets
> > > since it drop packets, not samples. But I am an option to work
> with
> > > samples.
> >
> > My suggestion is to focus on the "missed ISRs" first. I/O has to
> be reliable and
> > 100% solid before you worry about other things.
> >
> > How do you know an ISR is missed? One out of, say 100, ISRs would
> be very difficult
> > to see on a dig scope, so I'm wondering how you're detecting this.
> >
> > -Jeff
> >
> > > --- In c..., aram vartanian wrote:
> > > >
> > > > Most VOIP implementations drop or duplicate a whole
> > > > packet instead of samples. Instead of working in
> > > > samples try working in 10 millisecond packets. That
> > > > would be 160 samples at your 16 KHZ sampling rate.
> > > >
> > > > Since you are dropping 1 in 500 samples, this means
> > > > that 16000/500 = 32 samples would be thrown away or
> > > > duplicated every second. Therefore you would throw
> > > > away or duplicate one packet of 160 samples every
> > > > 160/32 = 5 seconds. This should not be noticable at
> > > > all.
> > > >
> > > > If the audio still sounds bad then you have some other
> > > > issue at the audio generation point.
> > > >
> > > > Aram
> > > > --- iewil2000 wrote:
> > > >
> > > > > I made a circular buffer of 20ms and inplemented
> > > > > sort of software pll
> > > > > (duplicating or dropping a sample). The statistics
> > > > > shows I dropped 1
> > > > > sample per 500 samples or so. Is that too much?
> > > > >
> > > > > I am thinking dynamic adding or subtracting CLKDIV
> > > > > of McBsp instead of
> > > > > dropping samples. But TI warned me not to change it
> > > > > on flying. Anyone
> > > > > has done that? I know you can do it during bootload.
> > > > >
> > > > > Although I can get statistics by run data stream and
> > > > > they all look
> > > > > fine, the audio still sounds terrible. I cannot say
> > > > > the method work yet.
> > > > >
> > > > > Wei
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> I use nested HWI to get back the missing ISR now. The software pll is
> also working, audio stream is clean.
>
> I saw missing ISR on scope because I missed far more that 1%. I think
> deeper memory will help.
Ok, that's great, good work. Do you still have trouble to match audio and packet
clock domains?
-Jeff
> --- In c..., Jeff Brower wrote:
> >
> > Li Wei-
> >
> > > I had two GPIO to monitor the ISR on scope. Those two ISR should
> be
> > > quite periodic, every 1ms for USB and every 10ms for DMA. But I
> did
> > > see missed ISR sometimes. Here I have question: does the USB HWI
> > > preempt DMA HWI in 55x chip as required by my design? 'BIOS/DSP
> one
> > > day workshop' says it doesn't if a dispatcher isn't used. I am not
> > > using BIOS/DSP. I do see USB HWI has higher priority that DMA in
> > > datasheet.
> > >
> > > Longer buffer is also been used: 10ms buffer for audio processing
> and
> > > I am adding or dropping 1ms buffer instead of samples. It sounds
> > > still noisy. Now I am suspicous ISR scheduling as aforemetioned.
> > >
> > > Is there any literature states the benifit of working with longer
> > > buffer instead of with samples? VOIP has to deal with 10ms packets
> > > since it drop packets, not samples. But I am an option to work
> with
> > > samples.
> >
> > My suggestion is to focus on the "missed ISRs" first. I/O has to
> be reliable and
> > 100% solid before you worry about other things.
> >
> > How do you know an ISR is missed? One out of, say 100, ISRs would
> be very difficult
> > to see on a dig scope, so I'm wondering how you're detecting this.
> >
> > -Jeff
> >
> > > --- In c..., aram vartanian wrote:
> > > >
> > > > Most VOIP implementations drop or duplicate a whole
> > > > packet instead of samples. Instead of working in
> > > > samples try working in 10 millisecond packets. That
> > > > would be 160 samples at your 16 KHZ sampling rate.
> > > >
> > > > Since you are dropping 1 in 500 samples, this means
> > > > that 16000/500 = 32 samples would be thrown away or
> > > > duplicated every second. Therefore you would throw
> > > > away or duplicate one packet of 160 samples every
> > > > 160/32 = 5 seconds. This should not be noticable at
> > > > all.
> > > >
> > > > If the audio still sounds bad then you have some other
> > > > issue at the audio generation point.
> > > >
> > > > Aram
> > > > --- iewil2000 wrote:
> > > >
> > > > > I made a circular buffer of 20ms and inplemented
> > > > > sort of software pll
> > > > > (duplicating or dropping a sample). The statistics
> > > > > shows I dropped 1
> > > > > sample per 500 samples or so. Is that too much?
> > > > >
> > > > > I am thinking dynamic adding or subtracting CLKDIV
> > > > > of McBsp instead of
> > > > > dropping samples. But TI warned me not to change it
> > > > > on flying. Anyone
> > > > > has done that? I know you can do it during bootload.
> > > > >
> > > > > Although I can get statistics by run data stream and
> > > > > they all look
> > > > > fine, the audio still sounds terrible. I cannot say
> > > > > the method work yet.
> > > > >
> > > > > Wei
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
