>IMO it would be much better if the link to details about the card would
>not say "Install' but instead indicate that details about the card can
>be found there (alsa soundcard matrix), I mean the column is named
>appropriately drivers&docs but the item in column is always 'Install'.
>It has mostly install info but also module options, known bugs etc.
But it's hard to think of another word that is more appropriate.
I think that for many people once they have found the link for their
card they will bookmark that and use the matrix very rarely after. Once
that is done the Matrix becomes near meaningless to an average user.
For people who haven't found the page yet they are most likely looking
for instructions about how to install the card. So INSTALL seems very
appropriate there.
However if people only want information about a prospective card it is a
different story. In that case a different word could be more
instructive. It would be nice to find the right one :)
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Hi all.
I have been working on a 'simple sampleplayer' that acts as an ALSA sequencer
client and can be used to play for example drum samples and loops.
Check the simsam homepage at http://simsam.sourceforge.net and download
via CVS.
There are still many things to fix... check the README for details.
Requirements:
ALSA 0.9
QT 3.0.x
libaudiofile
jack
Any feedback is welcome!
cheers,
Christian Henz
Hi,
I am working on a surround sound project. When finished this code will update a virtual acoustic environment based on a persons head motion. I am hoping for some hints on solving a problem I have. Note! My background is in signal processing, not software/hardware interfacing. So I am still clueless on the process of moving data between user memory and the sound card. Current development is done using ALSA.
My problem:
The current code can process the audio far faster then the sound card can except/output it. Therefore, to reduce the latency between head motion and changes in the sound output, I will need to keep the amount of data in the output buffer to a minimum. For the sake of discussion say about a 1024 frames (the exact amount is flexible) Currently I try to control the flow by pausing the output loop. My problem is that I keep getting buffer underruns, even when I am writing another 1024 frames of data to the sound card before 1024 frames have had time to play (which does not make any sense to me).
What I want to do is poll the data buffer so that I can determine the amount of data remaining in the buffer. So far I have only been able to determine (by polling) that the buffer is willing to accept new data.
So my question. Does anyone have a idea on how I can determine the percentage of fill in the output buffer?
I am also open to any ideas on keeping the amount of data queued for output to a minimum, in a controlled fashion.
Thank You
Dennis Thompson
*******************************************************************
Center for Image Processing and Integrated Computing (CIPIC)
Interface Laboratory
University of California, Davis CA 95616
Phone : (530) 754-9861
Fax : (530) 752-8894
e-mail : mailto:dmthompson@ucdavis.edu
URL : http://interface.cipic.ucdavis.edu/
*******************************************************************
> >Thats something that worried me, I seem to remeber that the sound of a
> >guitar changes if its not impedance matched with the AD converter. I'm
> >pretty sure, mine doesn't match passive guitars. My bass is active though,
> >and I dont have any DI boxes, so no choice anyway.
>
>
> likewise here.
The input impedance of a mixer is way too low for a guitar (10K vs. 1M
ohm for a guitar amp iirc). The resulting sound is dull when compared
with using a direct box.
anyone knows a suitable AD box that can
> team up with coaxial digital in?
I vaguely remember reading about some inexpensive a/d boxes that have
built in mic pre's and a switch for high impedance instruments, but I
don't remember their names. I use an active direct box.
Tom
re: tube amp simulations for guitar...
from the music-dsp mailing list...
Just thought I'd mention that the upsampling/nonlinear
processing/decimation process that Line 6 performs was also descibed in Hal
Chamberlin's Musical Applications of Microprocessors (1985 edition), pg.
120:
"One modification technique that does not always work well when done
digitally is nonlinear waveshaping. Since clipping and other waveshape
distortions are likely to generate strong high-frequency harmonics, alias
distortion can become a problem. If necessary, the distortion operation can
be done at a much higher sample rate at which the alias distortion is less
of a problem, then digitally low-pass filtered to less than half of the
system sample rate, and finally resampled."
------------------------
and from http://www.metaltronix.net/basic%20tube%20FAQ.htm
[how do i] have a smoother, less buzzy distortion?
- Use a lowpass filter somewhere inside the amp in the signal path to cut
higher harmonics; perhaps a capacitor to ground from the final preamp tube
grid or plate -or-
- Use series grid resistors to cut the high frequencies in and after
distortion stages
- Use a lowpass filter after the amplifier and before the speakers to cut
out some of the higher overtones.
How do I get...
* Blues distortion?
Made by overdriving preamp and power tubes a little, enough to just start
compressing the peaks of the waveforms, and not very much high frequency
content, by electronically cutting highs or running the signal into a
speaker cab that acoustically cuts highs.
Guitar Player magazine ran a construction article on this very topic,
modifying a Fender Bassman to be the "Ultimate Blues Machine". The article
ran in 1995, authored by John McIntyre.
A recently voiced although intuitively applied idea in distortion is that
tube distortion sounds best when each successive distortion stage is
overdriven by less than about 12db. This has the effect of keeping the tubes
inside the area where the signal is more compression-distorted than clipped.
That is what those resistive divider chains between distortion stages are
for inside those distortion preamp schematics. Mesa's distortion preamps are
another good example.
Overdriving a tube stage too much gives you harsher clipping, not the
singing, sweet distortion we want. To really get sweet, crunchy distortion,
keep each stage that goes into distortion no more than 6-9db into
distortion.
* Marshall/metal/Boogie/etc. distortion?
Made by massively overdriving preamp tubes until the original waveform is
massively compressed and clipped. Usually followed with a moderate amount of
high frequency cut to remove some of the "insect attracting" overtones
generated in the clipping process. There is commonly some output tube
overdrive in this process, too.
* Good distortion at low(er) volumes?
overdrive preamp tubes until you get the clipping you want, then feed a
limited amount of this to a power amp stage to get the loudness you want.
This is how master volume controls work.
-------------------------------------
All fuel for thought I hope.
Cheers,
Stuart
Recorded in an anechoic chamber at 44.1/16, stored by octave and
modulation.
http://theremin.music.uiowa.edu/MIS.html
"Please feel free to use these samples in your research or music projects
without restriction. You may also cite as a reference, link to our page
from another web page, or provide a link in a publication using the
following URL"...
Would be very useful for a linux soft sampler projects, hint hint ;)
- Steve
folks on ardour-dev and jack-devel will be aware of the email
nightmare i have faced over the last 4 weeks when it comes to using
any sf.net hosted mailing lists. first, my existing ISP destroyed the
SMTP configuration of the domain my email is sent to. then i
registered linuxaudiosystems.com with jumpline.net, and it turns out
that they too do not have their SMTP configuration correct. both
situations mean that sf.net's use of exim3's SMTP callback system for
verifying email sender addresses fail with either pbd(a)op.net or
paul(a)linuxaudiosystems.com and i have been unable to send mail to any
sf.net mailing list for more than a month.
i am writing to see if anyone has any experience of any web/smtp
hosting services that are (1) definitely configured to permit SMTP
callbacks to work correctly (2) appropriately priced (i.e. cheap!) and
(3) preferably handle domain transfers smoothly and efficiently.
i've set reply-to so that replies come to me rather than the
list. thanks for your input.
--p
> -----Original Message-----
> From: Paul Davis [mailto:paul@linuxaudiosystems.com]
>
> > that's ok, I don't think everything has to be
> understandable by a newbie,
> >it's not the wording of what's there that is a problem, it's
> the missing
> >information that's a problem (I just sent an update about
> what functionality
> >I have found missing in sb live, I guess more of that should
> be available
> >(for other cards) as well).
>
> just as a sort-of aside, i would note that a discussion on the
> vst-plugins list right now points out that the windows creative
> drivers for the audigy *do not* work in ASIO mode with ACPI turned
> on. to make them work, its necessary to "install the drivers in
> standard mode", whatever that means.
and I can't make rca inputs work in windows as well:-) in fact they work
even less than in linux - in linux the sound at least gets through the card
and I can hear it (not record it though) but in win98 they seem to be
completely dead.
> this information is not available on the creative web site. ALSA is
> not alone in this type of failure to document missing or incorrect
> functionality, and our existence as an open community makes it more
> likely that, with the correct documentation infrastructure, we can
> ensure that it gets added in a timely way.
yes, and to prove it I have already send an update and it's already on the
page!
erik
> -----Original Message-----
> From: Patrick Shirkey [mailto:pshirkey@boosthardware.com]
> Sent: Wednesday, October 23, 2002 1:49 PM
> To: linux-audio-dev(a)music.columbia.edu
> Subject: RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel]
> hel p for a levelmeter]
>
>
> > this is what's on the page:
>
> >Creative Labs | Soundblaster Live Platinum | EMU10K1 | Install |
> >(4)[A][B]
>
> > bottom of the page:
> >
> >(4) Hardware mixing supported
> >
> >...
> >
> >NOTE: Just because an I/O is listed does NOT mean it is
> guaranteed to
> >be supported. Please check the mailing
> >list archives before making purchase decisions based on
> requirements
> >forIEC958 or ADAT I/O.
>
> >[A] IEC958 RCA Input
> >[B] IEC958 RCA Output
>
> >which does not have a lot of informational value (I know
> what it does
> >not mean but what does it mean?) and it definitely does not imply
> there >is a problem of getting the docs to support certain
> functionality.
>
> Hmm. It has a certain informational value although I will
yes, but not useful when choosing sound card (as it appropriately says:-)
- which was my point.
> I'll try to think of a way to word it for users who may not have the
> requisite knowledge.
that's ok, I don't think everything has to be understandable by a newbie,
it's not the wording of what's there that is a problem, it's the missing
information that's a problem (I just sent an update about what functionality
I have found missing in sb live, I guess more of that should be available
(for other cards) as well).
> Apart from that at the top of the page it's explicitely
> stated that some
> companies have not provided the required docs to enable
> support for a
> device. I have always noticed those comments however it may
yes, but saying 'some companies' has close to no informational value.
knowing WHICH companies is crucial.
> just be my
> angle on things. I have made some changes to the matrix to be more
> obvious that even if we have the docs we may not have all the
> necessary
> parts. Although I would've thought that most people already know that
> about Linux hardware support.
again, having general knowledge is of no use... what does it help a user
to know that _some_ cards are better supported and _some_ manufacturers
offer better/worse docs? One needs to know the _specifics_ which are close
to impossible to find.
> As you know the known bugs section in the driver notes gives explicit
> information about things that we know do not work. I'll look making a
> form for adding specifically to this file.
IMO it would be much better if the link to details about the card would
not say "Install' but instead indicate that details about the card can be
found there (alsa soundcard matrix), I mean the column is named
appropriately drivers&docs but the item in column is always 'Install'. It
has mostly install info but also module options, known bugs etc.
> I would like to do that and also make it easier for people to
> post info
> about supported devices. I have most of the work done but not
> finished
> yet. As it is I currently stay up to 6:00 in the morning many
> nights of
> the month. I'm lucky though as I only have to work 16 hours a
> week in my
> paying job. I could be working many more hours but have made the
> decision to sacrifice some of my current earnings in order to build
> Boost Hardware and DJCJ. Along the way I have also picked up
> the alsa
> website :)
it's very important work and I hope that you'll bring it up so that it's
actually a good resource for information (at this point it's IMO in the
'almost' category (mostly speaking of soundcards I use, not sure how much
information there is for other soundcards)).
thanks a lot for doing it!
erik
> -----Original Message-----
> From: Paul Davis [mailto:paul@linuxaudiosystems.com]
>
> [ re: OSS ]
>
> >> code. It will
> >> soon be available only through emulation. It forces use of
> >> the blocking
> >> model.
>
> actually, it doesn't. nothing would stop the implementation of an OSS
> driver/client for JACK.
>
> >> ALSA is very powerful and complete, but very complex.
> This will make
> >
> > <rant>
> >
> > it is also pretty much useless for general users. I mean
> if I can't listen
> >to mp3 and browse the web at the same time ... (without
> sound servers which
> >were discussed recently and as far as I can tell the general
> consensus is
> >that they are bad and not to be used). Is there any rationale for the
> >blocking behaviour? I mean I can't imagine situation where I
> would want
>
> to clarify: the "blocking model" that joshua was describing has
> nothing to do with the "blocking behaviour" that you are describing.
> jaroslav (aka "mr. alsa") has justified the block-on-open model by
> reference to POSIX standards for the open system call. its a bit
> debatable, but his point of view on it is at least as close to
> standard POSIX behaviour as yours. applications can avoid this quite
> easily using O_NONBLOCK in the OSS open call (or its equivalent for
> ALSA), later followed by fcntl(2) if necessary.
>
> i personally it would have been better to make open return EBUSY, but
> the problem is that there is no flag for open(2) that says "block even
> if busy", so with that design there is no way to get "block-on-open"
> if desired.
IMO it does not matter how well justified it is by POSIX or whatever else
if the end result is unusable system. In case of 'file' files it makes
(some) sense to block, however in case of sound I can't really think of
realistic situation where I would want to block. It's either busy (and let
program handle that) or realtime mixing should be offered. If they are
concerned about POSIX that blocking could be defualt, user would be able to
change it to either non-blocking returning EBUSY or non-blocking real time
mixing (sw, if card does not support it in hw)
anyway, thanks for background info.
> > except of the blocking of sounds (the problem mentioned
> above) I am quite
> >dissapointed by functionality of linux drivers I have tried,
> I have sb live
> >platinum and (last time I checked):
>
> "i am quite disappointed that a group of volunteers who work for no
> monetary compensation have failed to implement all the features i
> want. i haven't offered to pay them, but i really hope they get all
> these features working really soon because its really irritating not
> being able to ..."
well:
- let's kill the messenger,
- that's what open source promises.
erik