At Wed, 15 Oct 2008 12:14:57 +0400,The Source wrote:> > Takashi Iwai пишет:> > At Wed, 15 Oct 2008 11:47:00 +0400,> > The Source wrote:> > > >> Takashi Iwai пишет:> >> > >>> At Wed, 15 Oct 2008 11:16:32 +0400,> >>> The Source wrote:> >>> > >>> > >>>> Takashi Iwai пишет:> >>>> > >>>> > >>>>> At Tue, 14 Oct 2008 15:24:22 +0400,> >>>>> The Source wrote:> >>>>> > >>>>> > >>>>> > >>>>>> By the way, note, that not rate may cause oops but number of channles > >>>>>> for example (wav that causes oops has mono mode and the one that just > >>>>>> plays silently - stereo. Also the oops sample is 16bit, silent one is > >>>>>> 24bit).> >>>>>> > >>>>>> > >>>>>> > >>>>> This is an important information. The driver basically supports only> >>>>> 16bit stereo samples natively. The others are covered by alsa-lib,> >>>>> and this involves with the mmap mode.> >>>>>> >>>>> But I still wonder why 16bit mode.> >>>>>> >>>>> OK, the below is *THE* test I'd like ask you guys to try first.> >>>>>> >>>>> - Build the driver with --with-debug=detect option> >>>>> - Load the driver with debug=2 module option> >>>>> - Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox> >>>>> - Raise the Master volume to the max> >>>>> - Run "aplay this.wav"> >>>>>> >>>>> At *each* run, check your kernel message. If you get Oops, copy the> >>>>> whole log immediately.> >>>>>> >>>>> - If you get a DMA error or so in the kernel message, try to define> >>>>> XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver.> >>>>> Run the same test.> >>>>>> >>>>> - If still any serious problem, load the module with debug=3 option,> >>>>> and get the whole kernel message with full register accesses.> >>>>>> >>>>>> >>>>> thanks,> >>>>>> >>>>> Takashi> >>>>>> >>>>> > >>>>> > >>>>> > >>>> I've done what you have asked. I've got no oopses or other things like > >>>> that. But again not sound. I've tried with debug=2 and debug=3. > >>>> Attaching the whole dmesg output.> >>>> > >>>> > >>> Thanks. Judging from your logs, it seems that the timer IRQ isn't> >>> generated as expected, or the pointer (SRCCA register read) doesn't> >>> work, or all broken.> >>>> >>> Could you try with XXX_SYSTEM_TIMER? This eliminates, at least, the> >>> timer issue.> >>>> >>>> >>> Takashi> >>>> >>> > >>> > >> I can't use system timer. changing #undef XXX_SYSTEM_TIMER to #define > >> XXX_SYSTEM_TIMER causes this:> >> In file included from /mnt/e/temp/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2:> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: > >> In function ‘sbxfi_timer_handle’:> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: > >> error: ‘status’ undeclared (first use in this function)> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: > >> error: (Each undeclared identifier is reported only once> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: > >> error: for each function it appears in.)> >> /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: > >> warning: too many arguments for format> >> > >> > Try the patch below. In case you're using snapshot tarball, apply it> > with -p2 on alsa-kernel directory.> >> >> > Takashi> >> > diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c> > index 9ff5fc4..d6b5b34 100644> > --- a/sound/pci/sbxfi/sbxfi.c> > +++ b/sound/pci/sbxfi/sbxfi.c> > @@ -249,7 +249,7 @@ static void sbxfi_handle_timer_callback(struct sbxfi *chip);> > > > static void sbxfi_timer_handle(unsigned long data)> > {> > - LOG(2, "TIMER ISR\n", status);> > + LOG(2, "TIMER ISR\n");> > sbxfi_handle_timer_callback((struct sbxfi *)data);> > }> > > >> >> > > Ok, I tested again and found that sound is actually played (with and > without system timer),
Good to hear a positive thing :)
> but:> 1. The volume is extremely low. I had not only set volume to maximum in > alsamixer but also set my audio 5.1 system volume to maximum to hear a > sound.
This sounds like an amp isn't turned on somewhere. Possibly a GPIOsetting.
Alexey, what about your hardware? Is it also so extremely low?
> 2. The sound is very slow and glitchy. It plays much slower that it > should and constant glitches occur.
The glitches might be the result of the rate inconsistency.How slow is it? Is it somewhat playing half-rate samples? You cancheck it on the normally running device, for example,
% aplay -traw -fS16_LE -c2 -r48000 SOME-96K.wav
will play 96kHz samples in 48kHz.
thanks,
Takashi_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
