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? > I just can't understand why the version with the copy callback worked > perfectly, but this PCM indirect stuff has been nothing but trouble. Yep. > Did I mention I am using ALSA 1.0.9b? Does that version have a buggy > PCM indirect implementation? I don't think so. The pcm-indirect stuff is all inline functions. > 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. > Can't I > just advance the pointer by 0x2000 words after writing each chunk? Which pointer? Note that "writing" to the hardware doesn't mean that the samples are "played". The hw_ptr is supposed to be the position currently played. Or, at least, it's the position where the last period was processed. The timer function is necessary to achieve this pseudo hw_ptr. Otherwise the driver has no way to tell apps the current position. Many apps would be confused if you simply pass the written position because it's not the right position (although the difference is not so obvious in your case because the available buffer/period size is small). > Here is my userspace PCM playback implementation that works *perfectly*. ... unless you use mmap mode, dmix, whatever. The mmap emulation doesn't work for codes like dmix at all. Takashi ------------------------------------------------------------------------- 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
