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

List:       kde-multimedia
Subject:    Re: Recording PCM audio with aRts
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-06-10 16:48:35
[Download RAW message or body]

Hi!

On Sun, Jun 10, 2001 at 03:04:49PM +0100, Rik Hemsley wrote:
> #if Stefan Westerfeld
> 
> > 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.

I agree. There are two different things here:

1. there will be more than one point within the aRts flowsystem from where
you might want to record (i.e. you might want to record just the output
that quake is playing to artsd, but not the mp3, or the soundcard input,
or ...)

2. there will be more than one mixer selection for recording - i.e. cd, mic,
line-in, ...

Whereas choosing 1. is possible by using the aRts API (by using an appropriate
Synth_BUS_DOWNLINK), choosing 2. is not.

Esd for instance also doesn't allow you to choose 2., and the OSS programming
guide recommends not to add subsets of mixer functionality to pcm style apps,
but instead recording from whatever the user selected using the mixer.

Nevertheless I agree with you that for the user it would be more convenient
to select it in the recording application, just as for the user it would be
more convenient if kmix and artscontrol would not be two seperate apps.

Currently, artsd does know nothing about the hardware mixer. The KDE2.2
multimedia meeting summary says about mixers:

=============================================================================
4. Mixer issues
=============================================================================

There was quite some discussion about mixers. The facts until now are:

1. kmix is about the hardware mixer only
2. aRts doesn't know anything about hardware mixers at all
3. artscontrol controls only what artsd does, which is among other things,
   controlling the output effect stack, midi instruments and so on
4. it might be nice to have aRts simulate a multichannel software mixer with
   effects

1. Stefan Schimanski is working on giving kmix pluggable architecture, that
will work on the base of the Qt object model and dynamic loading, so it
might be possible to easily plug aRts into kmix. A "one mixer for everything"
approach might be more useful from a user-point-of-view than the current split.

2. Still, the general problem might be that aRts itself has no real
"abstraction" for mixers in the IDL. There is the audiomanager thing that
assumes the following:

* there are apps that dynamically come and go
* there are destinations (in form of busses) where audio might get played or
  recorded
* you can assign apps to destinations

On the other hand, one possible kmix model for apps would be dynamically
appearing channels per app, i.e. a new quake channel would pop up once you
start quake (whereas the current aRts idea would be more like: there are
eight static audio outputs, audio01 .. audio08, and once you start quake,
you can assign it to one of these channels).

It might be nice to add an IDL based abstraction for "mixers", which will
work the same for hardware and software mixers. This would provide things
like network transparent (and language independant) mixer control. Maybe
it would also make a good addition to the "AudioManager" style mixer
interface we have now.

This abstraction would also make it possible to have different clients
access the mixer abstraction in a unified way. I.e. a Gtk frontend to
the mixer would use the same software/hardware mixer than the KDE frontend.
Turning the volume in the KDE frontend would make the sliders move int he
Gtk frontend as well.

3. Entierly getting rid of artscontrol might not be the way to go, as there
are midi related tasks in artscontrol which really don't belong into a
mixer. But somehow unifying mixing would be "user-friendlier" than what
we currently have.

4. aRts model is powerful enough to provide a multichannel, effect based
mixer as software (and thats little code), and it might be possible to add
that to artscontrol. Assignment of programs to channels is trivial. You
can have equalizers (Synth_STD_EQUALIZER), per-channel-effects and so on.
It will work on all applications. It should be implementable with not too
much work (less than 1000 LOC).

Whatever, this is a bit of a are research topic ;), and different things
need to be done.

Stefan Schimanski is working on the kmix plugin architecture (1).
Stefan Gehn wanted to have a look at the GUI side of building a mixer (4).
I can help with getting the necessary backend work done for (4).
=============================================================================

> > * 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 :)

Well, I think you can add a method to Synth_CAPTURE_WAV

  void setFilename(string filename);

that would be ok. In the end, you will maybe find out that you want to have
your own implementation of Synth_CAPTURE_WAV anyway (it's really simple code)
to allow 8bit recording, or mono recording or something like that, if that
is so, you can simply copy it, and make a derived one.

I don't want to add a filename attribute due do security implications.

> 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.

Well, monitoring the input is easy. Simply instead of doing

  Synth_AMAN_RECORD (or Synth_BUS_DOWNLINK)
        |   |
		V   V
  Synth_CAPTURE_WAV

do

  Synth_AMAN_RECORD (or Synth_BUS_DOWNLINK)
        |   |
		V   V
  SomeVolumeMeter   (for instance StereoVolumeControl, which is also used by
        |   |        artscontrol)
		V   V
  Synth_CAPTURE_WAV

> > 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.

Well, I hope I have explained properly what there is to know about aRts
and recording. It's up to you what do to with that knowledge. I would be
really really happy to see a simple recording app, and if it is limited
through aRts in what it can do right now, it will be still better than
no recording app at all. Btw, I am attaching the .arts file so you can
see what I was talking about.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

["capture_to_wav.arts" (text/plain)]

nameÊpture_to_wav
module=Arts::Synth_MUL
{
  id=4
  x=3
  y=2
  port=invalue1
  {
    id=5
    connect_to"
  }
  port=invalue2
  {
    id=6
    audio_data=0.14000
  }
  port=outvalue
  {
    id=7
    connect_to(
  }
}
module=Arts::Synth_MUL
{
  id
  x=6
  y=2
  port=invalue1
  {
    id
    connect_to#
  }
  port=invalue2
  {
    id
    audio_data=0.14000
  }
  port=outvalue
  {
    id
    connect_to)
  }
}
module=Arts::Synth_BUS_DOWNLINK
{
  id 
  x=4
  y=0
  port=busname
  {
    id!
    string_data=out_soundcard
  }
  port=left
  {
    id"
    connect_to=5
  }
  port=right
  {
    id#
    connect_to
  }
}
module=Arts::Synth_CAPTURE_WAV
{
  id'
  x=5
  y=4
  port=left
  {
    id(
    connect_to=7
  }
  port=right
  {
    id)
    connect_to
  }
}

_______________________________________________
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]