Re: Driver design question

[Lee Revell <rlrevell@joe-job.com>]

On Tue, 2006-10-24 at 17:01 +0200, Takashi Iwai wrote:
> At Mon, 23 Oct 2006 13:46:13 -0400,
> Lee Revell wrote:
> > 
> > On Mon, 2006-10-23 at 15:09 +0200, Takashi Iwai wrote:
> > > At Fri, 20 Oct 2006 16:12:48 -0400,
> > > Lee Revell wrote:
> > > > ~ # aplay /usr/share/sounds/test/phone.wav 
> > > > Playing WAVE '/usr/share/sounds/test/phone.wav': Signed 16 bit Little
> > > > Endian, Rate 44100 Hz, Stereo
> > > > hw_params: stereo yes, format 16bit, rate 44100
> > > > dream_pcm_open: channel 0x0 eight_bit 0x0 stereo 0x1 rate 0xac44
> > > > dream_playback_ack
> > > > dream_playback_copy: not running!
> > > > dream_pcm_start: channel is 0
> > > > dream_work_transfer: polling status byte returned 0
> > > > calling snd_pcm_indirect_playback_transfer
> > > > in dream_playback_copy: 0x4000 bytes DMA area 0xcdfb0000 sw_data 0x0
> > > > dream_playback_ack
> > > > dream_playback_ack
> > > > dream_work_transfer: polling status byte returned 0
> > > > calling snd_pcm_indirect_playback_transfer
> > > > dream_playback_ack
> > > > playback size is 0x1005
> > > > dream_playback_ack
> > > > playback size is 0x100a
> > > > dream_playback_ack
> > > > playback size is 0x100f
> > > > dream_playback_ack
> > > > playback size is 0x1015
> > > > dream_playback_ack
> > > > dream_playback_ack
> > > 
> > > The problem looks like the calculation of dream->playback_hw_ptr
> > > passed to snd_pcm_indirect_playback_pointer().  This must be a _byte_
> > > offset in the "hardware" ring buffer.  That is, it's between 0 and
> > > (rec->hw_buffer_size - 1).  You set hw_buffer_size = 0x4000, but
> > > calculate playback_hw_ptr as [0, runtime->buffer_size] and in frames.
> > > 
> > 
> > With your patches I still get a similar result:
> > snd_pcm_indirect_playback_transfer is only called once or twice and the
> > first chunk of sound repeats endlessly.
> > 
> > ~ # aplay /usr/share/sounds/test/phone.wav 
> > Playing WAVE '/uhw_params: stereo yes, format 16bit, rate 44100
> > sr/share/sounds/dream_pcm_open: channel 0x0 eight_bit 0x0 stereo 0x1
> > rate 0xac44
> > test/phone.wav' dream_playback_ack
> > dream_playback_copy: not running!
> > dream_pcm_start: channel is 0
> > : Signed 16 bit calling snd_pcm_indirect_playback_transfer
> > in dream_playback_copy: 0x4000 bytes DMA area 0xcdfb0000 sw_data 0x0
> > Little Endian, Rdream_playback_copy: polling status byte returned 0
> > ate 44100 Hz, Stereo
> > dream_playback_copy done
> > dream_playback_ack
> > dream_playback_ack
> > dream_playback_ack
> > calling snd_pcm_indirect_playback_transfer
> > in dream_playback_copy: 0x4000 bytes DMA area 0xcdfb0000 sw_data 0x16384
> > dream_playback_ack
> > dream_playback_pointer: 0x134
> > 
> > At this point playback hangs.
> 
> Hm, that's bad.  Is dream_get_mpu_data_poll_status_byte() function
> atomic?
> 

It won't sleep, but it could spin for milliseconds.  I think it's
probably not optimal to call from interrupt context...

> > Is it really necessary to make up a fake pointer like this?
> 
> The only reason for using a background transfer is the damn mmap
> mode.  Since mmap mode requires a DMA transfer without manual write
> operations, you must implement a pseudo DMA engine to transfer the
> data chunk in background.
> 

I think it's not required to support mmap - read/write only is
acceptable.

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642