Re: Re: [Alsa-user] fm801 driver status?

[Takashi Iwai <tiwai@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]

At Wed, 18 Dec 2002 14:28:09 +0100,
Friedrich Ewaldt wrote:
> 
> Hi Takashi!
> 
> Thank you very much for your work!
> 
> The last patch solved the problem. No system hangs anymore. Looking 
> back, I must say it was not *that* practical to reboot the system every 
> time I used the audio device :-)
> The sound quality is ok (I wouldn't expect it any better with this cheap 
> card). Using my impulse response program, I also recognized that the 
> overall D/A + A/D latency is constant (32 samples) as expected.

good to hear that!

> (I could 
> never see this before because using my cs46xx based xfire the latency 
> changes in the range of 200 - 258 samples with every run. Bad - the 
> xfire has much better sound quality. Is this a hint that pcm_link() 
> doesn't work with cs46xx or is this maybe due to the DSP structure of 
> the xfire?)
 
might be a chip limitation, but might be a dsp code which currently we
are using...


> Using aplay, at the end of the audio file the last played samples get 
> repeated once. This doesn't happen with 'play', 'cat somefile /dev/dsp' 
> or 'artsplay'. But when I cause an error beep in a shell, I first hear 
> the beep and then the last samples played back before by any program 
> like  aplay, play, xmms,... I can reproduce this as many time as I like, 
> i.e. the samples remain in the soundcard buffer all the time.
> Another issue regarding aplay: playing back mono wav with a sampling 
> frequency below 44k1, the sound get's crackled. This also doesn't happen 
> with the other playback programs.

hmm, this could have been a cause of the last hang-up.
the unexpected interrupt was not caught by the handler.

could you check /proc/asound/card0/pcm0p/sub0/hw_params for each case?
also, please try the attached patch (the drivers should be compiled
with --with-debug=full) and see what shown in the kernel messages.
this will print the current ply_ctrl register value.
the patch is to the latest cvs.  the cvs tree already includes the
last fix and some additions for pause/release and spdif-out.


> Now I don't know if these small problems result from playing back 
> through the alsa device directly or if they are caused by aplay. Sorry 
> to say I've no other native alsa app installed at the moment to do tests 
> (e.g. alsa output for xmms ...).
> 
> Takashi wrote:
> 
> >perhaps do you see something out in the kernel messages on console 10
> >(alt+f10) when the system hangs?  well, after hang up, you cannot
> >switch the console, but you can start aplay on a certain
> >console, switch with alt+f10 and wait until the playback is finished.
> >  
> >
> I can switch with alt+f1 .. +f6 to the consoles 1 ..6, alt+f7 is X, but 
> alt+f8 and alt+f10 only show a blinking cursor at the top. Does that 
> mean that there are no messages or are I'm doing something wrong? (I 
> don't see any messages that I can read in /var/log/messages afterwards)
 
not sure, but it should depend on the configuration or the
distribution.
anyway, it doesn't matter, the problem looks almost solved :)


Takashi

[-- Attachment #2: fm801-debug.dif --]
[-- Type: application/octet-stream, Size: 866 bytes --]

Index: alsa-kernel/pci/fm801.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/fm801.c,v
retrieving revision 1.25
diff -u -r1.25 fm801.c
--- alsa-kernel/pci/fm801.c	19 Dec 2002 11:22:33 -0000	1.25
+++ alsa-kernel/pci/fm801.c	19 Dec 2002 11:26:55 -0000
@@ -337,6 +337,7 @@
 		return -EINVAL;
 	}
 	outw(chip->ply_ctrl, FM801_REG(chip, PLY_CTRL));
+	snd_printd("trigger: ply_ctrl = 0x%x\n", chip->ply_ctrl);
 	spin_unlock(&chip->reg_lock);
 	return 0;
 }
@@ -409,6 +410,7 @@
 	chip->ply_ctrl |= snd_fm801_rate_bits(runtime->rate) << FM801_RATE_SHIFT;
 	chip->ply_buf = 0;
 	outw(chip->ply_ctrl, FM801_REG(chip, PLY_CTRL));
+	snd_printd("prepare: ply_ctrl = 0x%x\n", chip->ply_ctrl);
 	outw(chip->ply_count - 1, FM801_REG(chip, PLY_COUNT));
 	chip->ply_buffer = runtime->dma_addr;
 	chip->ply_pos = 0;