All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: about bt878/879
@ 2005-03-30 10:56 Peter Zubaj
  2005-03-30 14:08 ` Joe Hsu
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Zubaj @ 2005-03-30 10:56 UTC (permalink / raw)
  To: nagual.hsu; +Cc: alsa-devel

Hi,

Just blind shot: Maybe diffrence in crystal frequence. 8000 Hz on
bt878 is not 8000 Hz on AC97. 

Peter Zubaj

____________________________________
Vsetko o SuperStar
http://superstar.atlas.sk



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

^ permalink raw reply	[flat|nested] 5+ messages in thread
* about bt878/879
@ 2005-03-30 10:48 Joe Hsu
  0 siblings, 0 replies; 5+ messages in thread
From: Joe Hsu @ 2005-03-30 10:48 UTC (permalink / raw)
  To: alsa-devel

    I have a sound device which only offer bt878 digital audio at sample
rate 8000 HZ.  I modify the 'btaudio' module source( an OSS driver) and
then it works. But when I want to capture data from bt878 and play it 
back on AC97 codec in real time, underrun condition happens.(AC97)

    I've tried to modify the bt87x driver(alsa) to work for me but 
I apparently do not have the ability to make it work. Then I write 
a simple driver for bt878 and it works as follows:
    1. Allocate a fixed-size audio buffer
    2. Write audio raw data to that audio buffer in a circular way.
       (This also includes a write pointer to indicates the current 
       location in which the bt878 RISC program is writing data.)
    3. AP can mmap that buffer and read the value of the write pointer.

    I've tried that simple driver with storing raw audio data in the 
harddisk and then play it back later on AC97 codec(ALSA driver) with no
problem. But here comes the problem again when I try to capture data
and play it back in real time( still buffer underrun). I've used
interrupt-driven model in my program for playback. At first, the 
frames I captured and the available space(snd_pcm_avail_update) 
for playback is almost the same( or at a fixed difference). But after
few seconds, the available space for playback is larger and larger.
(The increasing rate is 1 frame every 1/125 second. One frame is 4
bytes long.) And I am quite sure I did not miss any capture data.

    Any one here can give some hints about this? I know full duplex
for same audio codec is already possible for ALSA. But when it comes
to two different audio codecs(apparently have different crystal clocks),
how can we record and playback in real time???
    Plz help. thanks.

    

-- 
The sun is shinny but the ice is slippery.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-03-30 23:08 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-30 10:56 about bt878/879 Peter Zubaj
2005-03-30 14:08 ` Joe Hsu
2005-03-30 17:31   ` Peter Zubaj
2005-03-30 23:08     ` Joe Hsu
  -- strict thread matches above, loose matches on Subject: below --
2005-03-30 10:48 Joe Hsu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.