Hi.
I recently wrote ALSA PCM and seq support for BRLTTY[1].
However, the fact that libasound.so.2 lives in /usr/lib does
present a little problem for us. BRLTTY needs to be run as
early as possible during startup, most likely before /usr is
even mounted. Linking against -lasound the traditional way therefore is quite
a bug, since the executable now doesn't start anymore if
/usr is missing.
We've solved this now by dlopen() and dlsym()'ing all the
symbols we actually need, and call our private function pointers instead
of the real library symbols. However, this solution is kind
of icky. At the same time, we wrote support for QNX, which
seems to have a early fork of ALSA as the QNX Sound Architecture (also
called libasound). QNX apparently already puts its
libasound.so in /lib, most probably because of this
problem.
I'd like to ask the community what you think about
moving libasound from /usr/lib/ to /lib/? With OSS, that
wasn't a problem at all, since the ioctl calls were simple
enough that there is/was no need for a wrapper lib. But
since ALSA kind of relies on that, wouldn't it make more
sense to have the lib in /lib so that early boot programs
can output sound too?
--
CYa,
Mario
Hi,
I've posted the following message in Rosegarden-devel mailing list, and
Michael pointed me to an old thread from you about the same subject:
http://www.mail-archive.com/linux-audio-dev@music.columbia.edu/msg03322
Attached is a little program summarizing what I have found about the file
format at this moment. I would like to know if you have more information,
ideas or want to collaborate in this task.
Regards,
Pedro
On Sunday 29 August 2004 01:50, Pedro Lopez-Cabanillas wrote:
> Hi,
>
> I have many old songs, stored as Cakewalk "WRK" files, and I don't use
> Cakewalk or Sonar anymore. I'm not planning to do so in the future, 'cause
> I'm sure I will use Rosegarden. Of course.
>
> So, I need to convert my old WRK files to Rosegarden. But the WRK file is a
> closed format, and not publicly documented. It will be necessary to reverse
> engineer it, to rescue my old loved melodies along with the pile of shit.
>
> My plan is to first write a 'cake2rg' standalone utility, to start learning
> the file format and meanwhile to produce some practical results. After
> that, I hope to be able to import the files directly into Rosegarden. This
> won't happen before 1.0-final.
>
> If somebody had the same idea and has the work almost finished, please let
> me know ;-). Let's avoid duplicated work.
>
> Comments, please.
>
> Regards,
> Pedro
It may be that this topic is already covered somewhere, but after much
searching over the past few days I have been unable to come up with a
comprehensive guide to what I am attempting to do.
(Note that I've never written something like this before but know enough
about Linux and how things work that I would probably understand a
higher-level discussion on the topic...maybe. [grins])
I am attempting to write a program that will capture and record digital
audio (in the form of PCM/AC-3 over S/PDIF). What I *do* with that data is
a secondary issue and not something I want to get into now.
The input to the "system" is a USB digital audio capture device. (I
currently have an Edirol UA-1D
(http://www.edirol.com/products/info/ua1d.html) and Creative Labs MP3+
(http://www.creative.com/products/product.asp?prodid=154) at my disposal.)
What I'm not sure of is what I am looking for (or what I should expect to
find). The S/PDIF stream that will be coming into the device may have PCM
or AC-3. My basic assumptions on this topic are that I will have to find
some /dev entry to open and read from to do the capturing itself, but from
everything I've read so far it doesn't look like the standard /dev/audio or
/dev/dsp devices would suffice.
So, there you have it. I'm looking for some pointers to get the ball
rolling and I'm positive I'll be able to pick it up from there...it's always
the first few steps that are daunting. The kind of questions I am asking
are:
1) With the USB audio device plugged in, what device would I need to open
to read the raw digital data?
2) Is there an API already available for reading this information? (I've
looked at OSS, but haven't gotten much into ALSA yet.)
3) Assuming I can get at *a* bitstream, what will it contain? Will it be
the S/PDIF stream from which I will need to extract PCM/AC-3, or will it be
the raw PCM/AC-3 itself?
Thanks.
Paul Braman
Paul dot Braman at NielsenMedia dot com
813-366-5053
Hi,
I'm pleased to announce a project which eventually should support
several Firewire-based breakout-boxes. Following boxes would be
supported:
- ESI QuataFire 610
- M-Audio Firewire Audiophile
- M-Audio Firewire 410
- M-Audio Firewire 1814
- Terratec Aureon 7.1 FireWire
- Edirol FA-101
Each of those boxes is using the same chip produced by the company I'm
working for. I got green lights from my boss to do write a driver for
linux. Of course, this is not a very simple task. Most information
which is needed for writing a driver is available as Standards. Well,
some information is not available as standards...
If someone is interested to participate in this undertaking I would be
very glad, because it is a large task and I have only little resource
left for this project. So it would take rather long to finish it and
I'm sure some of the LAD guys are eager to use something different
than an USB based breakout box.
Any serious hacker who signs a NDA gets access to all information and
will also have for access to hardware (test boards). If s/he is not
signing (for some reason) only the public available Standards most be
enough. Access to hardware can still be arranged (hopefully).
Anyway I have already started to code something but it is still at
very very very early stage and not good for anything. Therefore I
haven't loaded it up somewhere.
cheers,
daniel
1)Does anyone know what format digital audio is stored in for miniDVs?
I know the audio can be 12 or 16 bit and I know that (at least for the
tapes I have) SP is about 60 minutes and LP is about 90 minutes. So, I
figure the sample rates are probably something like 48kHz for SP and
32KHz for LP, but I haven't found a definitive reference, yet.
I ask because I've had a canon zr60 miniDV camcorder for about a year
and have recently started using it to collect sounds. For now I'm
recording from the analog output of the camcorder into my delta66.
Obviously, this is less than ideal, but far superior to the handheld
voice recorder analog cassette tape solution I've been using for the
past 8 years. :-]
2)I've briefly glanced over the web page for kino:
http://kino.schirmacher.de/article/static/2
It appears kino will handle recording the video from a ieee1394
connection and also includes a tool for stripping audio out of the video
to a wav file. Anyone here have any experience to share in using kino,
or any other package, to do something like this?
3)Does it matter what ieee1394 interface I get, or are they all
basically the same as long as there's kernel support for them?
Thanks in advance,
Eric Rz.
PS appologies if this has been discussed recently. I've been away on
vacation and haven't had time to follow the lists closely for 3-4 weeks.
-edrz
Hi Matt:
Thanks for the further clarification. I suppose that the simple fact
is that the Linuxadio community simply doesn't "number up" enough for
Coda to consider us any sort of market. Same old story. Yawn, heavy
sigh... But the truth is that I'm not really interested in Finale, I'm
interested in libre software, and my concern is for the continued
development of NE. It would be nice if someone would step up and take
the reins, and as I said earlier, that is my hope now for NE.
Would I buy Finale for Linux ? Probably, at least to see what the
hubbub is all about. Ditto for Cubase or really any other music app that
would run under my favorite OS, but I would want to make an equal or
larger contribution to the developers of functionally equivalent libre
software.
My two drachmas, of course...
Best,
dp
Polashek, Matthew wrote:
>Hi!
>I met with the president nd founder of Coda, (Now Makemusic!) a few months
>ago at work(Silver Burdett Ginn) and I asked him if they were going to
>publish a Linux version of Finale now that they have completed an OSX
>version. He said that his programming and marketing staff had brought the
>idea up but that they were not going to make a Linux version at this time.
>
>FYI.
>
>Matt.
>
>
Hi my name is Mark and I have been a silent member for two
years - having very little experience with the in's and out's of
Linux. For many years I have blindly believed that Linux is the
way to go - more because of the concept of Open Source which
ties in exactly with my own belief structure. I have supported
linux for years in the form of mail servers but my own knowing
has been lacking. Recently ( 2 months ago ) I reinstalled all my
systems without the comfort of partitioned disks and windows as
a safety net. To date I have re-installed my system close to ten
times. I am only now realizing that I may have a hdd problem or
hardware in general - although no errors are evident. I have a life
long ambition to make sound - to generate ecstacy - to move
energy - to drown people - to open portals of thought and
recreation to fly - to dream - to enlight. In reality I am stuck with
my finger on the reset button.
My setup - P4 - 256 ram - Slackware 10.0 - linux 2.6.7 -
My problem as an end user - is limitless - while the discussion
group handles issues like left or right up or down this or that it
seems as if you all live in Utopia with perfect systems. My
problems as a beginner are endless.
My linux thought is that the main difference between linux and
windows is that under windows everything is packaged i.e. that
one installation will actually get that desired product to work -
while under linux a lot more time is spent on finding the correct
patches mixes matches reading than end time using/producing.
Obviously linux has flexibility power stability way beyond the
confines of windows or mac but it is the tieing up of those 'loose
ends' which make it easier for a new user to get going that make
the ultimate difference. While windows users have licence issues
some linux users have other.
It matters little to me if one program does something in one way
as opposed to a different way in a different program - i.e. each
program is unique unto itself and should be learnt seperately. My
problem in this area has been to get them to work together or
through each other with results.
I return to my silent world of learning and eventually achieving in
linux but that's my two cents.
I believe in Linux and all that it stands for and wish no insult to
any. Thank you for this moment.
bye
Mark
Mark McBride
Cell 08 4414 6809
Tel.: +27 21 462 0044
Fax: +27 21 465 0277
Bitwise Computer systems
EMail : tech-support(a)bitwise.co.za
EMail : sales(a)bitwise.co.za
____________________________________________________________________________
The information in this e-mail is confidential and is intended solely for
the addressee. Access to this e-mail by anyone else is unauthorised. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted in reliance on this, is prohibited and may
be unlawful. Whilst all reasonable steps are taken to ensure the accuracy
and integrity of information and data, and to preserve the confidentiality
thereof, no liability or responsibility whatsoever is accepted if
information or data is corrupted or does not reach its intended destination.
KFM Radio (Pty) Ltd. will not accept responsibility for unauthorised use,
be it public or private, to express opinion, promote or demote individuals
or groups.
Hi all,
I'm in a similar situation. Within a couple of weeks I'll be buying a
new PC which (besides still running Windows) should be, say, at least
Linux friendly.
Since in this case I'm not tied to given legacy hardware, I'd rather put
in some components that are particularly suitable for Linux.
>From what I heard, culprits can be
- audio card
- graphics card (hi resolution, 1280+, no 3D game capability needed)
- and I assume MIDI interface as well (6 to 8 ports in+out)
Are there cards with rather good Linux driver support?
Are there cards better to avoid in Linux world, due to their poor driver
status?
Is there a Linux hardware FAQ site somewhere, with some recommendations?
Until now I've been using an Emagic AW8 audio card, which perfectly fits
my needs (don't really need 24/96k or oodles of audio ports).
For Windows I was considering an Emagic AMT8 or Unitor8 interface, but I
don't remember seeing any Linux drivers on their site (well, they may
call'em OS X drivers... ;-)
Another component may be somewhat outside this list's topics, I'm
thinking of adding a video MPEG input/encoder card as well - maybe somebody
can give me any pointers on that...?
regards
Chris
On Tue, 24 Aug 2004 04:16:39 +0000 Thomas Pickett wrote:
> >On Sunday 22 August 2004 04:37 pm, Frank Barknecht wrote:
> > > Hallo,
> > >
> > > There are many more (pci cards), a very popular one being the RME card.
>
>
> Can anyone suggest a good RME Card? I have looked at their website but was
> wondering if anyone had personal preference. I preferably would like a
> sound card with mutilple in/outs, mic in/outs, midi, spdif.
>
> Once again I appreciate all the feedback. As for distros, I'm leaning
> towards debian, but I will do some more research.
>
> Thanks,
> Thomas
On Wed, 2004-08-25 at 17:52, Paul Winkler wrote:
> On Wed, Aug 25, 2004 at 06:02:44AM +0000, philicorda wrote:
> > Paul Winkler wrote:
> >
> > "I could swear I remember seeing an old tube compressor that
> > had a gain reduction meter with "more" to the right, so it
> > moved in opposition to the corresponding VU meter.
> > No idea what model it was, and this was about 6 years ago
> > so I could be mistaken.
> >
> > I wonder how consistent this is in the world of hardware?
> > maybe I'll pop a question on rec.audio.pro."
>
> btw, i had myself turned around again :-)
> If the gain reduction meter is moving in opposition the VU meter,
> then "more" gain reduction is to the left, not right.
>
> > I built a tube compressor like that, an Altec436c.
> > The 'gain reduction' meter measures the bias current of the vari-mu
> > valve, which is reduced when gain reduction is required.
> > The meter goes from right to left. (Any other way would require more
> > circuitry, so I think it may just be a lucky accident.)
>
> ah, that's an interesting point.
>
> > Talking of meters, don't some phase meters often go left *and* right
> > from a centre point to show averaged phase difference between the channels?
>
> think so.
>From the wide variety of responses describing all types of meters, it
seems that the HIG should steer clear of this topic and leave it the
developer's responsibility to make your meters intuitive. HIGs are not
about restricting the range of functionality you can implement, they are
just there to prevent needless usability regressions (aka usability
bugs). An example of a usability regression would be when a user
expects the leftmost menu to be 'File' and the 'Save' option to be found
in it, but then encounter some app which puts the 'Save' option on the
'Edit' menu. Since neither way is intrinsically better, the former is
the correct choice, because that is the way users expect it to work.
Is there any known broken meter behavior that we should prohibit? So
far I have not seen an example in this thread.
Lee
