Subject: RE: [linux-audio-user] 24bit 96khz cards that work well
From: Brian Redfern (bredfern_AT_calarts.edu)
Date: Tue Dec 31 2002 - 02:17:44 EET
Yup, my machine is only 533mghz pIII, so I'm really pushing it with the
stuff I do, however since I switched back to sblive and am working with
soundfonts I'm getting really decent low latency. Muse is working ok, jack
is working ok, now the goal is to write tunes using Muse and the
soundfonts and then record direct to disk with jack and arecord. The
sblive value card really is a nice, low noise card considering it cost me
all of $30 (the oem version).
On 30 Dec 2002, Jan "Evil Twin" Depner wrote:
> Mark,
>
> JACK supports 96KHz. I'm using the same chipset on my DSP24 card (ST
> Audio DSP2000 C-Port). I get some xruns but that comes with the
> territory. If I increase the buffer size to 2048 and use the card's
> digital mixer (via envy24control) to monitor I don't usually have any
> problems (running at 96KHz). On the other hand, I'm running an Athlon
> XP 1700+ and using fvwm2 to reduce use of system resources. I have,
> apparently, the worst combination of hardware - envy24 chipset, VIA
> KT133A chipset MOBO, Athlon processor but the ST Audio web site had some
> good advice on this combination.
>
> Jan
>
> On Mon, 2002-12-30 at 17:03, Mark Knecht wrote:
> > Anthony,
> > It could be a huge number of things, but like you I doubt it's just
> > interrupts. As you say, no card is going to generate more interrupts than it
> > needs to. Some cards could require a few more interrupts to get the job
> > done, but I doubt they'll generate that many more interrupts.
> >
> > More likely is the quality of the DMA controller in the sound chip, and how
> > well it gets the data across the bus. If a card has to deliver 1024 bytes,
> > and can do that in one burst of 256 cycles, while another card delivers the
> > same 1024 bytes in 8 bursts of 128 bytes, the first card will be much more
> > efficient and better behaved in the system, and probably use less PCI time
> > doing it.
> >
> > This is also HEAVILY driven by what the chipset will allow a PCI device to
> > so, hence my RME and your RME cards, while identical, might give different
> > performance results because our PC chipsets give it different access to
> > system resources like memory.
> >
> > To answer Brian's original question, I don't think Jack yet supports 96K,
> > but the RME cards do, and they work pretty nicely. Unfortunately they are
> > not inexpensive...
> >
> > One thing I hope Brian understand is that not every xrun is caused by the
> > sound card. Many (IMO most!) xruns are potentially caused by the disk
> > subsystem. Study that machine carefully Brian!
> >
> > With best regards,
> > Mark
> >
> > -----Original Message-----
> > From: linux-audio-user-admin_AT_music.columbia.edu
> > [mailto:linux-audio-user-admin_AT_music.columbia.edu]On Behalf Of Anthony
> > Sent: Monday, December 30, 2002 2:15 PM
> > To: linux-audio-user_AT_music.columbia.edu
> > Subject: Re: [linux-audio-user] 24bit 96khz cards that work well
> >
> >
> > * Brian Redfern <bredfern_AT_calarts.edu> [Dec 30 02 14:03]:
> > > Well, I figured out that the culprit to my xrun problem wasn't my 533mghz
> > > processor, its my envy24 chipset based card, from the alsa wiki:
> > >
> > > "Many but not all users complain about sound glitches. This may be due to
> > > the cards being IRQ hungry. (VU meter interface?) -- Tobiah"
> > >
> > > Given that the evil envy24 chip is in a lot of cards out there, I'm
> > > wondering what cards people have had better results with?
> > > http://www.brianredfern.org
> > >
> >
> > Also, out of interest, what does IRQ hungry mean? Isn't the frequency
> > of interrupts determined by HW parameters you choose? How can there be
> > any 'extra' interrupts. You mentioned in an earlier thread that your
> > SB card didnt seem so interrupt hungry, but are you sure the device is
> > opened with the same params? I'm no expert. Can anyone explain this?
> >
> > --ant
> >
> >
>
>
>
This archive was generated by hypermail 2b28 : Tue Dec 31 2002 - 02:16:51 EET