2009/9/7 Manuel Jander manuel.jander@gmail.com
Hi Raymond,
On Mon, Sep 7, 2009 at 3:47 AM, Raymond Yausuperquad.vortex2@gmail.com wrote:
On Thursday 03 September 2009 21:10, Manuel Jander wrote:
does anybody still have a AU88x0 card ? I know they are quite ancient now, but if anyone could give the attached patch a try ? Would be nice. I made the patch against linux-2.6.30.4 http://micro.homelinux.net/~mjander/au88x0.diff.gzhttp://micro.homelinux.net/%7Emjander/au88x0.diff.gz<
http://micro.homelinux.net/%7Emjander/au88x0.diff.gz%3E
Best Regards, Manuel
Which version of audaicous (1.5.x or 2.1) are you testing ? (alsa-gapless or alsa-ng plugin)
au88x0 most likely cannot support 1 sample per period because of the FIFO as described in patent 6167465.
Well, that is clear to me now. Using a DMA transfer that is smaller than one audio sample is not really a good idea. I would be better off using PIO instead of DMA.
if you look at the source code of alsa-ng and alsa-gapless plugin both of them use the own way to calculate the buffer size instead of using snd_pcm_hw_params_get_buffer_size()
http://hg.atheme.org/audacious-plugins/file/2c0a9bba77d7/src/alsa-ng/alsa-co...
CHECK_FAIL (snd_pcm_hw_params_set_access (pcm_handle, hwparams, SND_PCM_ACCESS_RW_INTERLEAVED), "snd_pcm_hw_params_set_access"); CHECK_FAIL (snd_pcm_hw_params_set_format (pcm_handle, hwparams, afmt), "snd_pcm_hw_params_set_format"); CHECK_FAIL (snd_pcm_hw_params_set_channels (pcm_handle, hwparams, nch), "snd_pcm_hw_params_set_channels"); CHECK_FAIL (snd_pcm_hw_params_set_rate (pcm_handle, hwparams, rate, 0), "snd_pcm_hw_params_set_rate"); CHECK_FAIL (snd_pcm_hw_params (pcm_handle, hwparams),
"snd_pcm_hw_params");
bitwidth = snd_pcm_format_physical_width(afmt); bps = (rate * bitwidth * nch) >> 3; buf_size = MAX(aud_cfg->output_buffer_size, 100); ringbuf_size = buf_size * bps / 1000;
I increased the minimum period bytes value to 256 in that patch. Audacious version 2 (Debian SID) works for me.
well, audacious.i386 1.5.1-9.fc10 cannot play any music (alsa plugin) on my au8830 with your patch, it only play music with (oss plugin)
Use xmms instead of audacious since they have similar UI
256 seem much bigger than the figures mentioned in the patent , may be it is the practical limit on your VIA ITX
In one embodiment of the present invention, the FIFO buffer is 32 samples or words in depth, which would withstand a maximum bus latency of about 4 microseconds. By way of example, if 48 DMA channels trigger simultaneously, with a trigger level set at half the buffer size (16 samples), each DMA channel can wait 16 samples (20 microseconds per sample), or approximately 320 microseconds before running out of data.
By way of example, CPU 210 may update-sub-buffer tables 380(0)-380(x) routinely every 10 milliseconds. The periodic checks may be initiated by audio processing peripheral 230 by way of interrupts, or may be scheduled independently by the driver
How do you get the "ADB Ctrl failure" error ?
I do not know how to reproduce that. Sometimes it happens, and its not possible to recover without a hardware reset (unload and load module). Somehow it semes to happen when my computer gets really hot (watching an MPEG-4 video, or compiling the kernel...). Its a old VIA ITX board, with a 1.3GHz processor (on demand cpufreq).
The patch tries to reset the audio card if all PCM streams are released once such a condition was detected. This is the situation were the windows driver used to crash the whole machine.
it work quite well on my two motherbroad using intel chipset
There are two main problem of the au88x0 driver
- alsa is unable to calculate the correct value for the three
functions snd_pcm_hw_params_set_buffer_time_near() , snd_pcm_hw_params_set_period_time_near() and snd_pcm_set_params()
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1724
Test case :
alsa-lib/test/pcm_min.c ( change default to hw:0,0 )
Real world case:
gstreamer and winealsa.drv
I will try that. I had no idea about that bugs.
A simple workaround is add another constraint
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 4096 );
however winealsa.drv will be using a larger period bytes than wineoss.drv
- unable to recover when the number of available src is not enough
(FATAL: ResManager: resource type 1 exhaust)
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2228
test case :
running application to use 15 src ( 7 stereo and one mono stream ) and open another stereo stream
Hmm, the good ol' resource manager :) OK, I will try to find a solution. I have not much time these days, but maybe it rains again, and I get bored, who knows :D
Best Regards, Manuel
simple fix may be adding counts of the resource and check that all resources are enough before allocating them