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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
