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

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

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...@yahoogroups.com, Jeff Brower <jbrower@...> 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
>

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

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

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 <l...@gmail.com> 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

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...@yahoogroups.com, aram vartanian <aramv@...> 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 <liwei2000@...> 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
>

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...@yahoogroups.com, aram vartanian <aramv@...> 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 <liwei2000@...> 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 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...@yahoogroups.com, Jeff Brower <jbrower@...> 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...@yahoogroups.com, aram vartanian <aramv@> 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 <liwei2000@> 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
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >

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...@yahoogroups.com, Jeff Brower <jbrower@...> 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...@yahoogroups.com, aram vartanian <aramv@> 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 <liwei2000@> 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
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >

--- In c...@yahoogroups.com, Jeff Brower <jbrower@...> wrote:
>
> 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

Jeff,

The audio and packet clock are matched. I drop or add 1ms buffer 
instead of sample. It sounds good. Now I have other things to take 
care of. When I call a subroutine, which worked in other project with 
5510, in DMA ISR, the program halted and I see PC points to an 
address lower than 0x00100, where is not in the definition of my 
command file. What's the possibility except stack overflow? My stack 
is 4000.

Wei

Wei-

> The audio and packet clock are matched. I drop or add 1ms buffer
> instead of sample. It sounds good.

Ok, that sounds impressive.  Good work.

> Now I have other things to take
> care of. When I call a subroutine, which worked in other project with
> 5510, in DMA ISR, the program halted and I see PC points to an
> address lower than 0x00100, where is not in the definition of my
> command file. What's the possibility except stack overflow? My stack
> is 4000.

I don't understand your comment... do you mean you call a function while inside the
DMA ISR?  If so, what registers does that function use?  Possibly you have not saved
enough registers upon entry to the ISR.

-Jeff

--- In c...@yahoogroups.com, Jeff Brower <jbrower@...> wrote:
>
> Wei-
> 
> > The audio and packet clock are matched. I drop or add 1ms buffer
> > instead of sample. It sounds good.
> 
> Ok, that sounds impressive.  Good work.
> 
> > Now I have other things to take
> > care of. When I call a subroutine, which worked in other project 
with
> > 5510, in DMA ISR, the program halted and I see PC points to an
> > address lower than 0x00100, where is not in the definition of my
> > command file. What's the possibility except stack overflow? My 
stack
> > is 4000.
> 
> I don't understand your comment... do you mean you call a function 
while inside the
> DMA ISR?  If so, what registers does that function use?  Possibly 
you have not saved
> enough registers upon entry to the ISR.
> 
> -Jeff
>

Your guess is correct. DMA ISR called a function with heavy memory 
use and somehow PC (register) pointed to an address undifined in the 
command file. But I think I don't need to save any register upon 
entering the ISR, since ISR is defined as "interrupt void DMAISR()".

Wei

Wei-

> --- In c...@yahoogroups.com, Jeff Brower <jbrower@...> wrote:
> >
> > Wei-
> >
> > > The audio and packet clock are matched. I drop or add 1ms buffer
> > > instead of sample. It sounds good.
> >
> > Ok, that sounds impressive.  Good work.
> >
> > > Now I have other things to take
> > > care of. When I call a subroutine, which worked in other project
> with
> > > 5510, in DMA ISR, the program halted and I see PC points to an
> > > address lower than 0x00100, where is not in the definition of my
> > > command file. What's the possibility except stack overflow? My
> stack
> > > is 4000.
> >
> > I don't understand your comment... do you mean you call a function
> while inside the
> > DMA ISR?  If so, what registers does that function use?  Possibly
> you have not saved
> > enough registers upon entry to the ISR.
> >
> > -Jeff
> > Your guess is correct. DMA ISR called a function with heavy memory
> use and somehow PC (register) pointed to an address undifined in the
> command file. But I think I don't need to save any register upon
> entering the ISR, since ISR is defined as "interrupt void DMAISR()".

I'm not sure about that... I don't remember if the 'interrupt' keyword causes the
compiler to examine only the ISR function itself to determine what regs to save, or
also all functions that it calls.  You might want to carefully check this.

-Jeff