Re: [Isisalsa-devel] Re: dmesg error with beta2

[Pieter P. <pie...@st...>]

Felipe Sologuren wrote:

> Pieter Palmers wrote:
>
>> Please don't install gcc 3.1! Upgrading to gcc 3 is something you can
>> easily spend a few days on.
>> Besides, this isn't the problem in this case.
>
>
> You are right, the problem isn't resolve.
> Now I have RH9 (upgraded) with same kernel and gcc 3.2. (I have some 
> time thinking in upgrade, isn't a problem, BTW :)
>
>>
>> Did you load the pci64.bin firmware with maxiinit?
>
>
> Maxinit don't have problems. When you release the firmware loader, I 
> haved 2 strange responses, but isis works. Now I have 0 strange 
> responses. 

I assume this means that the driver now works for you?

If it doesn't I have the following suggestions:
1) Your card seems to be running on IRQ 9. It might work better when 
forced to use IRQ5. You can do this by assigning IRQ5 to the PCI slot 
the isis is in, in the bios.

 >00:07.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E 
(rev 10)
 >    Subsystem: Guillemot Corporation: Unknown device 0010
 >    Flags: bus master, medium devsel, latency 128, IRQ 9

2) I also notice that you are using another soundcard that is also on 
IRQ9. The isis driver doesn't support IRQ sharing (yet). Forcing the IRQ 
of the isis to 5, like suggested above, could solve this problem. Or, as 
I suspect that this is the on-board soundcard of the mainboard, you 
could disable this on-bord sound.

 >00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 
AC97 Audio Controller (rev 10)
 >    Subsystem: Avance Logic Inc.: Unknown device 4710
 >    Flags: medium devsel, IRQ 9


The dmesg log tells me that it is definately an IRQ problem. Maxiinit 
doesn't use interrupts to communicate with the ISIS, therefore it 
doesn't report any errors. The first error statement in the dmesg log 
('ALSA sam_io.c:345: sam9407: command 0x3 ack timeout') corresponds with 
the first time the driver expects a response from the sam chip (for 
which it needs to receive an interrupt).

>
>
> Thank you again, Pieter.

No problem

>
> Felipe.
>
> PD: Other question: capture from your driver don't work because 
> Maestro driver from Alsa don't do it?
> (Is this an extra problem for you?)
>
The only capture that is implemented is the one from the maestro driver, 
and as I based on the standard es1968 driver of the ALSA package, it 
suffers from the same problems as this driver. And indeed, I saw some 
posts on the alsa-devel mailing list about the capture part of the 
es1968 not working with the maestro2E. I haven't tried myself, but I 
assume this applies to the isis maestro driver as well.

I don't intend to correct this problem myself, I'll leave it up to the 
es1968 maintainers. I don't know how the maestro PCM stuff works. 
Besides: all capture with the isis should be done through the SAM part 
anyway. The maestro recording is lousy compared to the SAM recording.

I should also mention that I suspect that this linux driver lowers the 
card's latency by a factor 2 or more, as compared to the windows driver. 
Havent been able to test this statement though.
There are two reasons for this lower latency:
1) the ALSA framework provides far better latency specs than the 
equivalent windows framework. (if you use a low latency kernel)
2) My driver uses a variable hardware buffer size, whereas the windows 
driver uses a fixed buffer size of 4096 stereo samples. When 
applications use the "default" alsa settings, this results in a buffer 
size of 2048 stereo samples, which corresponds to 4.2ms.

But this is theory, let's wait & see if it's really true.

Ciao,

Pieter