Yet.
Has anyone got an idea of the schedule for including
ALSA into the devel kernel series ?
--markc
> "if we get everyone to switch to alsa, then everyone can share audio
> interfaces".
>
> "if we teach everyone how to use LD_PRELOAD and they accept it, then
> everyone can share audio interfaces without even switching to ALSA."
Well this sounds like a win-win situation and we should advertise
On Saturday 15 December 2001 11:31 pm, Paul Davis wrote:
> >Even the Alesis MasterLink buffers to disk first. Can you say 'Buffer
> >Underrun"? Real-time burning is hard to do right, without a faster-than
> >real-time buffered source. Of course, BURN-Proof helps.
> sorry, but this is not true.
On Sun, 16 Dec 2001, Jussi Laako wrote:
> Mark Constable wrote:
> > Linux audio got screwed over by Linus allowing a semi-commercial
> > "product" to be embedded within the kernel 7 or so years ago. It
> > has taken this long for any adequate replacement to come along,
> > which is ALSA.
> ALSA wa
Hi Martijn,
Comments inline:
martijn sipkema wrote:
> > There are a small number of issues to fix, but the basic concept of
> > having MIDI controllers broadcast data over a TCP/IP network and DMIDI
> > hardware clients translate this data into raw MIDI (in as close to
> > real-time as I can ge
"M. Edward Borasky" wrote:
>
> Or, you can spend a few grand US and get a dummy head with the
> microphones built in.
Yes, but dummy head is not good as your own head and ears. Shape of the head
and auricle makes big difference.
> Or, you can take ordinary audio streams and pump them through
On Sun, 16 Dec 2001 23:32:23 +0100
"martijn sipkema" <[EMAIL PROTECTED]> wrote:
> i'm not an expert on cd recording devices, but these do not allow the
> change of recording speed whilst recording, do they?
Recording speed is set by the sample rate.
> and does s/pdif have flow control?
No.
On Sun, 2001-12-16 at 05:35, Richard Guenther wrote:
>
> Well, most important for developers is not end-user documentation, but
> API documentation - this part can be most easily done by the developer(s)
> who did implement the API rather than someone else trying to figure out
> whats going on by
> There are a small number of issues to fix, but the basic concept of
> having MIDI controllers broadcast data over a TCP/IP network and DMIDI
> hardware clients translate this data into raw MIDI (in as close to
> real-time as I can get) seems quite stable.
>
> The protocol is very simple, and do
> sorry, but this is not true. go and get a tascam dedicated cdrw
> unit. it works 100% of the time, perfectly, with a s/pdif real time
> input. at least, the one i have access to does. it can only do "audio
> time" burning, but given the dedicated nature of the beast, thats
> ok. i very much doub
> -Original Message-
> I personally like to play with real ear -recordings. Just put small high
> quality mic capsules to ear plugs and put those into your ears
> and record to
> DAT. Now you have recorded _real_ 3D soudscape. Listen with headphones.
Or, you can spend a few grand US and g
Paul Davis wrote:
>
> >So what you are saying is "if we get everyone to switch to alsa and use
> >alsa properly, (i.e. writing apps which send buffered audio data to the
> >alsa-server in a timely fashion)" the need for a separate sound daemon
> >will disappear. Right?
>
> Almost.
>
> "if we ge
>> my studio/drumming friend (who has loads of experience with this
>> stuff) will sometimes use 12 tracks just to record a rythmn
>> track. this lets him play with the role of each drum in the piece in a
>> way that sticking a stereo mike above a drumset just doesn't permit.
>
>I'd like to note t
>and many people don't like freeverb or gverb.
Both are rather poor reverberators, yes. People has to be very
careful in parameter settings and to what sounds to use the reverbs.
I would like to hear about people who have tested gverb. If nothing
else I at least would know who could test next ve
Paul Davis wrote:
>
> my studio/drumming friend (who has loads of experience with this
> stuff) will sometimes use 12 tracks just to record a rythmn
> track. this lets him play with the role of each drum in the piece in a
> way that sticking a stereo mike above a drumset just doesn't permit.
I'd
Yikes! The good news is you're OK; that's what's really important.
Take care of what matters; LAD will still be there when you're back.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University
Charles Iliya Krempeaux wrote:
>
> Maybe you (or someone else) could work on getting POSIX.4 implemented
> in the Linux kernel. POSIX.4 is the "real time" (i.e., "real world")
> POSIX API.
Yes, I'm still waiting for someone to implement named message queues to
kernel which are base of all real
Mark Constable wrote:
>
> Linux audio got screwed over by Linus allowing a semi-commercial
> "product" to be embedded within the kernel 7 or so years ago. It
> has taken this long for any adequate replacement to come along,
> which is ALSA.
ALSA was not ready at that time, still isn't and maybe
Ivica Bukvic wrote:
>
> I am still extremely bothered by the fact that Linux does not have a
> decent sound daemon which would solve all of our troubles in respect to
> having /dev/dsp resources hogged by a particular application, as well as
> backwards compatibility with esd and arts compatible
Someone emailed me asking for details about the problems with the envy24
chip. I lost who emailed me, and this should probably be on alsa-dev, but
the person who knows more about it is Bill Evans. His email address is
[EMAIL PROTECTED]
-- Forwarded message --
Date: Sun, 16 Dec 2
There's a diff at http://www.acooke.org/andrew/writing/diff-libkmid-alsa that
changes libkmid in KDE 2.2.2 so that it compiles with Alsa 0.9. Additional
changes are necessary to the config script (workaround decribed at
http://www.acooke.org/andrew/writing/tonto.html#kmid).
This is my first
>So what you are saying is "if we get everyone to switch to alsa and use
>alsa properly, (i.e. writing apps which send buffered audio data to the
>alsa-server in a timely fashion)" the need for a separate sound daemon
>will disappear. Right?
Almost.
"if we get everyone to switch to alsa, then e
Hey,
We are all glad you are ok !
vini
(looking suspiciously at the fire our neighbour is making)
andrew cooke wrote:
>deviceman.cc:294: aggregate `struct snd_seq_client_info_t clienti' has
>incomplete type and cannot be initialized
they want total opacity for all their structs in alsa, so you need
snd_seq_client_info_malloc() and friends from alsa-lib. consequently,
you need to use the acc
Greetings:
Last week the apartment building immediately adjacent to mine burned
to the ground. A firewall between the buildings prevented flame damage,
but my apartment suffered significant smoke damage. One room is
completely destroyed, all my clothing is ruined, and all of my property
is smok
Hi List,
I'd like to introduce DMIDI, a protocol for transmitting MIDI over a
TCP/IP network.
The project will be fully released over the next few weeks and I'm
making it available to you all for feedback/flames.
There are a small number of issues to fix, but the basic concept of
having MIDI co
Hi,
I'm trying to update the KDE midi handling code to work with Alsa 0.9 (at
least, I think that's what I'm doing - it doesn't compile as it is). While I
can work out what routines to use etc from the source, I'm a bit confused by
the typedefs. In particular with:
#include
#include
I get
On Fri, 14 Dec 2001, Lamar Owen wrote:
> On Friday 14 December 2001 04:45 am, Alexander Ehlert wrote:
> > > audio current limitations log," right? :). You have said it the best:
> > > Linux overall, is acutely suffering from lack of coherent documentation,
>
> > Every programmer should write the
28 matches
Mail list logo
