Paul Davis wrote:
(sorry for the off-topic post, but i want people
on these lists to have the first chance at this)
Rev 1.5 Hammerfall Digi9652
all cables
Windows/Mac driver CD
original packing materials
current street price: about $580
asking price: $480 OBO + shipping
rats. i jus
Hmm...
I guess Paul can throw in an signed(!) linux driver CD.
Let the bidding start :-)
/RogerL
On Tuesday 04 March 2003 23:13, Sebastien Metrot wrote:
> Huh, no linux driver CD? I'm not interested! (ok, easy one, sorry :-).
>
> Sebastien
>
> PS: I allready own one, great stuff, don't hesit
Huh, no linux driver CD? I'm not interested! (ok, easy one, sorry :-).
Sebastien
PS: I allready own one, great stuff, don't hesitate.
- Original Message -
From: "Paul Davis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, 04 March, 2003 22:47
Subject: [linux-audio-dev] [OT] [
(sorry for the off-topic post, but i want people
on these lists to have the first chance at this)
Rev 1.5 Hammerfall Digi9652
all cables
Windows/Mac driver CD
original packing materials
current street price: about $580
asking price: $480 OBO + shipping
On Tue, 2003-03-04 at 05:12, Thomas Vander Stichele wrote:
> Hi,
>
> > The only disadvantage I see in the above scheme is that there is some
> > duplication of code between PortAudio and gstreamer. But this seems
> > irreconcilable; GStreamer isn't useful for Multimedia-editing
> > applications (
>>and as i will discuss at the LAD meeting at ZKM in 2 weeks, writing
>>audio software like this has the easy-to-fall-into trap that arecord
>>demonstrates: a basic design that falls apart as soon as a few basic
>>assumptions turn out to be false.
>
>Will notes or slides from the talk be available
>and as i will discuss at the LAD meeting at ZKM in 2 weeks, writing
>audio software like this has the easy-to-fall-into trap that arecord
>demonstrates: a basic design that falls apart as soon as a few basic
>assumptions turn out to be false.
Will notes or slides from the talk be available afterw
On Tuesday 04 March 2003 10.20, [EMAIL PROTECTED] wrote:
[...]
> > Exactly - and that is why you must design in a way that allows RT
> > hosts and plugins to operate without non RT safe actions.
>
> yes and because a nonRT system can do more things it is a superset
> of RT. (but this is just being
>> in general, the best answer is typically:
>>
>>arecord -d plughw:0
>
>Ok, so this is probably associated to the output of arecord -L then, which
>seems to be listing all "plugins" that can be used as pcm input ? I think
>I'm starting to understand slowly. Is there some doc explaining out
Hi Paul,
> in general, the best answer is typically:
>
>arecord -d plughw:0
Ok, so this is probably associated to the output of arecord -L then, which
seems to be listing all "plugins" that can be used as pcm input ? I think
I'm starting to understand slowly. Is there some doc explaining
On Tue, Mar 04, 2003 at 09:56:36AM -0500, Paul Davis wrote:
> >On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
> >> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
> >>control port is likely to be most meaningful to the user if
> >>displayed as a meter. Can be
>On Mon, Mar 03, 2003 at 10:12:14 -0500, Paul Davis wrote:
>> /* Hint LADSPA_HINT_OUTPUT_METER indicates that the value of output
>>control port is likely to be most meaningful to the user if
>>displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
>>if the meter should use
>On Mon, Mar 03, 2003 at 09:36:09 -0500, Taybin wrote:
>> Why have both? Couldn't the absence of one imply the presence of the
>> other? And if there are both, it also implies that there are third and
>> forth states of both and neither.
>
>I think there is meter and/or text (ie. both if ou suppo
>-d should allow me to specify a device, but I have no idea in what syntax
>this is for which card. I tried a few things:
>- specifying 0 and 1
>- specifying 15 and 15_1, the card ids
>- specifying "spdif" (based on output of arecord -L, but I don't know how
>I would choose between cards in that
We've posted an update about our forthcoming 24/192 portable recorder:
http://www.core-sound.com/HighResRecorderNews.html
It runs on an iPAQ and the Linux version of the software uses Familiar/GPE
and ALSA.
Thanks to all for the high level of interest!
Len Moskowitz
Core Sound
On Mon, Mar 03, 2003 at 08:36:04PM +, Simon Jenkins wrote:
> [EMAIL PROTECTED] wrote:
>
> >On Sun, Mar 02, 2003 at 09:06:02PM +, Simon Jenkins wrote:
> >
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>
> >>
> >>>ok ... now to the API...
> >>>
> >>>
> >>>
> >>Here's my thinking so far,
Hi,
> The only disadvantage I see in the above scheme is that there is some
> duplication of code between PortAudio and gstreamer. But this seems
> irreconcilable; GStreamer isn't useful for Multimedia-editing
> applications (unless they were built from the ground up to use it), and
> I doubt GSt
On Fri, Feb 28, 2003 at 07:05:19PM +0100, David Olofson wrote:
> On Friday 28 February 2003 09.20, [EMAIL PROTECTED] wrote:
>
> > ok... but i see realtime as a subset of offline audio processing...
>
> It is not. Real time applications have some very strict requirements
> that no other applicatio
>
>Paul: (2) above may make you nervous, but look at it this way. You have
>said in the past that every Mac OS X application is capable of
>interchanging audio data out of the box, thanks to CoreAudio. The flip
>side of that coin is that CoreAudio was written to be usable by every
>application e
Hi Paul,
thanks for the quick answers, I tried things as soon as I got back.
I've been experimenting some more (sometimes analogue audio is so much
easier to debug), and I'm slowly learning stuff, but I haven't been able
to actually record things yet.
So, on to some more questions ...
> there
On Mon, Mar 03, 2003 at 09:36:09 -0500, Taybin wrote:
> Why have both? Couldn't the absence of one imply the presence of the
> other? And if there are both, it also implies that there are third and
> forth states of both and neither.
I think there is meter and/or text (ie. both if ou support bot
Paul Davis writes:
> the kernel gives non-SCHED_FIFO/RR threads roughly 1/HZ
> resolution.
Seems to be 20 ms on my unpatched standard SuSE 2.4.19.
I imagine this can be lowered by modifying the kernel config ?
> SCHED_FIFO/RR threads can get better than that if the
> delay is very small, but
22 matches
Mail list logo
