[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Kde-multimedia digest, Vol 1 #211 - 9 msgs
From:       Marc Siegel <mlsiegel () static-243 ! marcy ! brown ! edu>
Date:       2001-06-12 15:44:07
[Download RAW message or body]

Hey, I see a problem here. Am I correct that this precludes recording
two seperate tracks at the same time from two seperate sources? It should
be possible to do that if you ever want multi-track recording to be useful.

-Marc

> > aRts currently uses no explicit selection of input sources, neither
> > for midi nor for audio. Rather the current strategy is through the
> > (Audio|Midi)Manager objects. This works like that:
> >
> >   1. you start recording (playing), describing what you do
> >
> >   2. there are predefined points where you can record data from (play
> >   data to),which the user can connect your application to through
> >   artscontrol
> >
> >   3. the next time your application records (plays) again, it will be
> >   connected to the same point again
> >
> > It might be that you might want to change something in there, but
> > thats the way it works right now.
>
> This sounds to me like you're saying it's impossible to select an input
> source with the aRts API and that the user would have to run artscontrol
> to choose an input, right ? This isn't very nice for the user, as they
> would probably prefer to just start the audio recording program, pick
> an input (mic/line-in/cd/whatever) and press record.
>
> > * opening, reading, closing:
> >
> > Well, recording is still somewhat on the aRts TODO list, but here is an
> > overview what works and what does not.
> >
> > A. recording with server-side objects
> >
> > Creating a Synth_AMAN_RECORD (which does that AudioManager thing), and
> > connecting it to a Synth_CAPTURE_WAV is the simplest style of
> > recording.  It will create a wave file in /tmp/mcop-<username>/... - I
> > did hardcode that for now because of security considerations (what if
> > you get an .arts file by mail that "records" some file which already
> > exists and thus overwrites it? or creates a file which you - as
> > stupid user - will never find again?).
>
> You say you hardcoded the location that is saved to - so how would I go
> about working around this ? Saving in /tmp isn't very useful.  My /tmp
> is in RAM :) Also, I'll want to monitor the input with level meters, so
> the user can see that their input is working. If the data is going
> directly to a file behind my back, I won't be able to do that.
>
> > So... as conclusion I'd say, it would be great if you write that simple
> > recording application (we really really need that), and fix things on
> > the way. (/me currently always uses artsbuilder with .arts files to do
> > recording, which is probably not the ideal thing).
>
> Sorry, I don't want to spend a lot of time learning about aRts internals
> and fixing stuff, I just want to write very simple audio recording app.
>
> If aRts doesn't support recording properly yet, that's ok, I'll just
> drop the idea.
>
> Rik
>
>
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]