Hi, At Fri, 16 Nov 2001 11:32:33 -0500 (EST), Chris Meadors wrote: > > On Thu, 15 Nov 2001, Takashi Iwai wrote: > > > The card has still not tested enough with the latest driver. > > Please give us any feedback for any problems/comments. > > Not much to say yet. But I did get to mess around with the card a little > bit last night. I need to get a new harddisk before I can do any serious > work (I mostly work with video, and have too many uncompressed DV streams > laying around). > > What I really need to do is find some ALSA native multitrack software and > really go to town (can SoundTraker not do software mixing and send 8 > seperate tracks to 8 seperate channels?) Ardour will be the best choice on Linux (except for its complexity of compiling :)
> The first thing I noticed (even before when the driver wasn't loading). > My BIOS desided to assign the sound card to the same interupt as my SCSI > controller. > > Any time I am moving a lot of data to disk I get these errors: > > ALSA pcm_lib.c:116: Unexpected hw_pointer value (stream = 0, delta: -1, > max jitter = 3276): wrong interrupt acknowledge? > > Is this because of the shared interupt? Is there anything the ALSA driver > could do to avoid acknowledging the wrong interrupt? I know idealy the > sound card and SCSI controller should be on seperate interupts, I'll work > on convincing my BIOS to do that. I think the ALSA driver itself plays its role correctly. The warning message appears when an interrupt comes too later than expected. So, it depends quite on the system - as you noticed, mostly on disk system. Perhaps tuning via hdparm might help. > The other problem I noticed was xruns (what is the exact defination of > that?) when doing something silly like piping the output of cdparanoia > straight into aplay. Probally shouldn't be doing that anyway, but just an > observation. Hmm, basically ice1712 driver needs to allocate a big chunk of contiguous memory as a buffer. Since it must be always for 10 channels with 32bit regardless how many channels/formats are used, the buffer size required is much higher than other normal consumer cards. And I guess it's the problem of aplay - aplay can use very small period/buffer size.. Maybe it'd be better to allocate a big memory at the boot time and keep it just like rme9652 driver does. > Oh, where do the names for the sliders in alsamixer come from? I have > ADC, ADC1, ADC2, ... ADC7. Kinda fooled me for a second. ADC should > really be ADC0, or ADC1 making ADC7 become ADC8. Same goes for the DACs. Use envy24control rather than alsamixer. envy24control supports the things which alsamixer cannot do, such as choosing an enum list, and even looks better :) > I couldn't get the envy24control program to compile, but that might just > be my machine as my gtk stuff is pretty messed up right now (again need a > new hard disk to fix it up right). I'm thinking it will probally give me > a little better view of the card than alsamixer. amixer seems to have a > lot of bits to frob, but I didn't get into the documemtation too much for > it yet. Yes, you really should try envy24control.. ciao, Takashi _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
