Java Sound Resources: FAQ: Audio Programming

You have to use SourceDataLine/TargetDataLine.available(). The usual implementation for streaming audio (in Java Sound) is a dedicated thread for that - look at the Java Sound Demo which you can download from Sun or at the Java Sound Resources: Examples. (Florian)

Apparently, most Java Sound implementations do not provide that, even if the soundcard supports it. Future implementations will support that. (Florian)

TargetDataLines are supposed to act as a "direct" way to communicate with the audio hardware device, i.e. your soundcard. When your soundcard does not support μ-law directly, the TargetDataLine won't either.

The way to go is to open a TargetDataLine in pcm format and route it through a format converter. See doc of AudioSystem to get converted Streams. The converted stream you get provides μ-law samples then.

There is no drawback in this approach: all PC soundcards that I know of deliver only PCM, so it has to be rendered to μ-law anyway in software. Whether in the soundcard's driver, the operating system layer or in the application (your java program) doesn't matter. You get maximum portability when only using pcm for TargetDataLines. (Florian)

This depends on the soundcard and its driver to the native operating system. E.g. Soundblaster 16 or 64 do not provide real full duplex, only a kind of pseudo full duplex. I experienced under Windows that you can only use this pseudo full duplex when you have a certain order in opening record/playback lines. (Florian)

Due to problems with some OSS drivers, full-duplex is disabled by default in versions up to 1.4.1. There are several ways to get full-duplex:

See also Q: 3.3 (Matthias)

Obtain the list of available Mixer implementations with AudioSystem.getMixerInfo(). Select one of the available and call AudioSystem.getMixer(Mixer.Info) to obtain the Mixer. With this object you can call Mixer.getLine(Line.Info) instead of AudioSystem.getLine(Line.Info). In the JDK 1.5.0, you can also use the ease-of-use methods in AudioSystem:

With the JDK 1.5.0, there is an additional possibility: The default provider properties can be used to select the default Mixer for each type of line (SourceDataLine, TargetDataLine, Clip, Port). The default Mixer, if available, is used in AudioSystem.getLine(). For details, see the specification. (Matthias)

The implementation of the "Direct Audio Device" queries the soundcard driver for the supported formats. Some ALSA drivers do not support mono lines, so they are not available in the "Direct Audio Device". The workaround is to open a stereo line and expand the mono data to stereo. See also How can I convert between mono and stereo? and How can I make a mono stream appear on one channel of a stereo stream? (Matthias)

Well, nobody really knows why this fancy naming was chosen. From the perspective of an application, it's counter-intuitive. To understand it, take the perspective of a Mixer object: It receives data from the application via a SourceDataLine object, this is its source of data. And it delivers data to the application via a TargetDataLine. So from the perspective of the Mixer, this is the target of its data. (Matthias)

The implementation of these methods in the "Java Sound Audio Engine" is bad and will not be fixed. The "Direct Audio Device" has a much better implementation. See also What are all these mixers?

But keep in mind that it is not possible to get a frame precise playback position with these methods. There is too much buffering in the data path (also in the audio hardware), so calculating the position is always only an estimation.

If you try to measure the precision of DataLine.getMicrosecondPosition() with a real-time clock, you are also likely to see the effect of a clock drift. For details on this phenomenon see Why does recording or playing for a certain period of time results in audio data that is shorter or longer than the period I recorded / played? (Matthias)

DataLine.getLevel() is not implemented in current versions of the Sun JDK (1.4.1), nor in any other known Java Sound implementation. Here is a suggestion from Florian Bomers on how to implement this functionality yourself:

(Matthias)

This is an issue where even the Java Sound gurus do not know a satisfying answer. A useful definition would be the following:

However, this is not the way it is implemented. For the "Direct Audio Device" mixers, isActive() and isRunning() always return the same value. In general, it is recommended to use isActive(), since it is specified less ambigously and it is implemented consistently. See also bug #4791152. (Matthias)

The following is working reliably at least with the "Direct Audio Device" mixers:

(Matthias)

This is Florian's (and my) opinion:

(Matthias)

There are two possibilities:

(Matthias)

There are two possibilities:

(Matthias)

This can be avoided easily: after writing all data to the SourceDataLine call drain() and stop(). If you want to reuse the line after this, call start() again before writing more data to the line. (Matthias)

The reason is a common misconception about how Line.open() works. According to the specification, open() without parameters opens a line in a "default format". The default format of a line is an implementation specific property. It is not the AudioFormat used in the DataLine.Info object. Rather, the format in DataLine.Info is used to request a DataLine instance that is capable of handling this format. This does not necessarily mean that the line has to be opened in that format. Note that it is possible to construct DataLine.Info with an array of AudioFormat objects. This means that the requested line has to be able to handle any of the given formats.

The Java Sound implementaion prior to JDK 1.5.0 had the following property: If only one AudioFormat is given in a DataLine.Info, this AudioFormat becomes the default format of the line. This caused the behaviour that it was possible to specify the format for open() via the DataLine.Info object. However, this behaviour was never specified, it is just an implementation specific property you can't rely on in general. The "Direct Audio Device" mixers in JDK 1.5.0 beta (see also What are all these mixers?) behave different: they just pick one of the supported hardware formats as default format. This is a correct behaviour according to the specification, since the specification doesn't specify how the default format is chosen.

Therefore, it is recommended to always specify the format when opening a DataLine: use open(AudioFormat format) or open(AudioFormat format, int buffersize) rather than Line.open() without parameters. See also Line.open(), SourceDataLine.open(AudioFormat), SourceDataLine.open(AudioFormat, int), TargetDataLine.open(AudioFormat) and TargetDataLine.open(AudioFormat, int)

AudioFormat format = ...;
DataLine.Info info = new DataLine.Info(SourceDataLine.class, format);
// line is *capable* of being opened in format
SourceDataLine line = (SourceDataLine) AudioSystem.getLine(info);
// open in default format, not necessarily the same as format
line.open();

AudioFormat format = ...;
DataLine.Info info = new DataLine.Info(SourceDataLine.class, format);
// line is *capable* of being opened in format
SourceDataLine line = (SourceDataLine) AudioSystem.getLine(info);
// open in desired format
line.open(format);

It was decided to change the behaviour for the final version of the JDK 1.5.0 to provide backward compatibility with the JDK 1.4. The former unportable technique will be specified behaviour. See also bugs #5053380 and #5067526 (Matthias)

You can use the system mixer of your operating system to select the recording source in the same way you would do it for a native program. With newer versions of the Sun JDK, you can achieve the same by using the interface javax.sound.sampled.Port. See the section Ports for details. (Matthias)

Current implementations of the Java Sound API do not support multiple TargetDataLines for the same recording source. There are no plans to change this behaviour. If, in the future, multi-channel soundcards are supported, it may be possible to get different TargetDataLine instances for the different inputs. If you just want to "split" lines, do it in your application. See also Can I use multi-channel sound? (Matthias)

Well, because it's a bug. The above is true for the Sun JDK up to version 1.4.2 on Solaris and Windows, and up to 1.4.1 on Linux. Beginning with version 1.5.0 for Solaris and Windows and version 1.4.2 for Linux there are the new "Direct Audio Device" mixer that don't have this limitation.

Tritonus is unaffected by this limitation. (Matthias)

This is a bug that was fixed for 1.4.2. If you have to use an older version, there are two possible workarounds:

(Matthias)

The obvious solution would be to get a Control object of type VOLUME or MASTER_GAIN for the TargetDataLine and manipulate the volume via this object. However, this is not possible, since no known Java Sound implementation supports any controls for TargetDataLine instances.

What you can do is to use the system mixer to control the recording volume --- it affects hardware settings in the soundcard. One possibility is to use the mixer application of the operating system. The other possibility is using Port lines from inside a Java Sound application. See the section Ports for details.

The remaining possibility is to implement a volume control digitally: multiplying each single sample of the sound data with a certain value that lowers or raises the level proportionally. See also Change the amplitude (volume) of an audio file (Matthias)

It is specified that TargetDataLine.drain() has to wait until all data has been delivered to the TargetDataLine. If the line is not yet stopped, there is always data being delivered to the line. So you should call drain() only after stop(). In fact, drain() isn't needed with TargetDataLine at all.

A common technique to terminate reading from a TargetDataLine is the following:

TDL.stop();
do
{
    count = TDL.read();
}
while (count > 0);
TDL.close();

For an implementation of TargetDataLine.drain() to be 100% compliant you need to block when the line is started and there is still data available. One way to do this is the following:

public void drain()
{
    while (isActive() && (available() > 0))
    {
        Thread.sleep(100);
    }
}

(Matthias)

By specification, TargetDataLine.read() is a blocking call: it waits until the requested amount of data is available. To use read() in a non-blocking manner, you can check how much data is available with available() and request only that amount. If you want to use read() in a standard blocking manner, but need quick response for a real-time application, use smaller buffers for reading. See also What is the minimum buffer size I can use? (Matthias)

Even after calling stop() on a TargetDataLine, there may be data remaining in its internal buffer. Make sure you read data until there is no more available. Then you can call close() on the line. See also How should I use stop() and drain() on a TargetDataLine? (Matthias)

For files of this size, you should stream the audio. Like that you treat buffers of small size and feed them successively into the audio device. Look at the Java Sound Resources: Examples, there are some streaming audio players to take as a start. (Florian)

This happens with the "Java Sound Audio Engine" when too many clips are open. While you can obtain any number of Clip instances, only 32 can be open at the same time. This is a hard limitation of the engine; it can only mix 32 channels. As a workaround, you can close unused clips and open them once they are needed again. If you really need more than 32 channels, you can do the mixing in your application and output the result to a SourceDataLine. (Matthias)

Stop the clip by calling stop(), then use clip.setFramePosition(0) or clip.setMicrosecondPosition(0). Alternativly, you can set looping points so that rewinding occurs automatically: clip.setLoopPoints(0, -1) (In this case you have to call clip.loop(...) instead of clip.start().) (Matthias)

getFramePosition() and getMicrosecondPosition() are specified to return the position corresponding to the time since the line (or clip) was opened. If you want to get the position inside the loop of a looping clip, you can use something similar to this (assuming you are looping over the whole length of the clip):

currentFrame = clip.getFramePosition() %
clip.getFrameLength();

(Matthias)

This is a bug, and apparently one not easy to fix. See bug #6251460. Note that you can work around this issue by using the old "Java Sound Audio Engine" instead of the "Direct Audio Device" mixers. This way, you get the same behaviour as in 1.4. See also What are all these mixers? (Matthias)

Lines from these mixers do not provide controls in 1.4.2. In Florian's original opinion, "any control would obscure the initial idea, to provide high-performance direct audio access". However, he changed his mind and implemented volume and balance controls in 1.5.0. (Matthias)

In music, pan knobs are used for mono input lines to control how they are mapped to stereo output lines. On the other hand, for stereo input lines, the knob is labelled "balance". So you should get a PAN control for mono lines and a BALANCE control for stereo lines (and none for lines with more than 2 channels).

In the Sun J2SDK, PAN controls behave like BALANCE controls for stereo lines and BALANCE like PAN for mono lines. However, this is only a convenience for compatibility. To write portable programs, you should not rely on this behaviour. (Matthias)

To implement a PAN control for a mono line, it has to be "distributed" between the left and right channel of a stereo line. This was no problem with the "Java Sound Audio Engine". The "Java Sound Audio Engine" always opens the soundcard in stereo, so it is always possible to do this "distribution". The "Direct Audio Device" implementation, however, opens the soundcard in mono if a mono line is requested. So it's not possible to implement a PAN control for such lines.

The workaround is to work with stereo: convert your stream to stereo and open the SourceDataLine in that stereo format. Then this line will have a BALANCE control, which works like a PAN control. See also How can I convert between mono and stereo? and What is the difference between a BALANCE and a PAN control? Which one should I use? (Matthias)

Gain (FloatControl.Type.MASTER_GAIN / FloatControl.Type.VOLUME) controls are still available with the "Direct Audio Device" mixers in 1.5.0 (see also What are all these mixers?). However, the behaviour has been changed so that controls are only available after the line has been opened. This was necessary because in general, some control are only available if the device driver supports certain features, which can be queried only after the respective device has been opened. (Matthias)

Clip and SourceDataLine instances provide a FloatControl.Type.MASTER_GAIN control rather than a FloatControl.Type.VOLUME control to control the playback volume. See also Why does obtaining a gain control work with 1.4.2, but not with 1.5.0? (Matthias)

The "Direct Audio Device" mixers in 1.5 (see What are all these mixers?) do not provide a sample rate control. To cite Florian:

As an alternative, you can resample your data with a sample rate converter to achieve the same effect. See also How can I do sample rate conversion?

Or, you can still use the sample rate control of the "Java Sound Audio Engine" with 1.5 by requesting lines directly from it. See How can I get a Line from a specific Mixer? (Matthias)

Obviously, this depends on the operating system, the hardware, the Java VM, which Mixer implementation you use and several other factors. The following measurements have been found experimentally on a very old PC (350 MHz) under Linux with the Sun JDK 1.4.2_02:

These measurements suggest that the latency introduced by buffers in the "Java Sound Audio Engine" is about 50 ms, independant of the sample rate. (Matthias)

This happens with the "Direct Audio Device" of the JDK 1.5.0 if the line is opened with open(AudioFormat) instead of open(AudioFormat, int). The reason for this behaviour is that by requiring a certain buffersize or range of buffersizes in DataLine.Info, you obtain a line that is capable of setting its buffersize to the respective value. You still have to choose the actual value. This is done when opening the line: with open(AudioFormat, int), a certain buffer size for the line can be specified. If open(AudioFormat) is used, the line is opened with the default buffer size. Until 1.4.2, a buffersize in DataLine.Info was used in opening if the open() call does not specify a buffer size. However, it was decided that automatically taking over this value is a questionable convenience. (Matthias)

The DataLine implementation of the "Java Sound Audio Engine" has a circular buffer per line instance. For SourceDataLine instances, write() writes data to this buffer. A separate thread reads from the circular buffer and transfers the data to the native layer of the engine. This allows for arbitrary sized buffers, but results in the overhead of an additional buffer and one thread per DataLine.

The DataLine implementation of the "Direct Audio Device" of 1.5.0 does not have a circular buffer. Instead, it writes/reads data directly to/from the soundcard driver. This gives higher performance and lower latency. On the other hand, it restricts buffer sizes to what the soundcard driver supports.

Adding a layer of buffering to the "Direct Audio Device" mixers would result in the same performance penalty as the DataLine implementation of the "Java Sound Audio Engine". It would introduce a general overhead though the additional functionality is only needed in special cases. Therefore, it is unlikely that the implementation of the "Direct Audio Device" mixers will be changed to allow larger buffers.

If you need larger buffers, you can implement an additional layer with a circular buffer in your application. Then you can choose any size you want for this buffer. And note that you need an additional thread — like the "Java Sound Audio Engine". The Answering Machine has classes that do a similar job. There is also the class org.tritonus.share.TCircularBuffer in Tritonus that you can use for this purpose. (Matthias)

There are several implementations of Mixer in Java Sound:

Note that what Java Sound calls "Mixer" is different from what Windows calls "Mixer":

See also How can I find out which Mixer implementation is used? (Matthias)

There are mixer that only provide TargetDataLine instances. In the Sun JDK up to 1.4.2, SourceDataLine instances are only provided by the "Java Sound Audio Engine", while TargetDataLine instances are only provided by the "Simple Input Device" mixers. This is subject to change for JDK 1.5.

Starting with version 1.4.2, there are additional mixers that provide only Port instances. See also What are all these mixers? (Matthias)

With the Sun JDK 1.4.2 or earlier on Windows, you can set the default audio device to the telephone device: Control panel -> Multimedia (or Sounds...) -> Preferred Device. With the "Direct Audio Device" mixers of the JDK 1.5 it is also possible to use the default provider properties to set the default Mixer / MixerProvider inside Java Sound.

See also Why are there mixers from which I can't get a SourceDataLine?, How can I capture from a specific source (microphone or line-in)?, How can I get a Line from a specific Mixer? and Why can I record from different soundcards, but not play back to them? (Matthias)

For the Sun JDK, this is possible with version 1.4.2 and later for Linux and with version 1.5.0 and later for Solaris and Windows. For Tritonus, this is possible with the ALSA Mixer implementation. (Matthias)

This is true for Solaris and Windows for Java versions up to 1.4.2. There, playback is only possible via the "Java Sound Audio Engine", which always uses the first soundcard. On the other hand, recording in these versions is done with the "Simple Input Device", which provider one Mixer instance per soundcard.

With the "Direct Audio Device" mixers, it is possible to choose different soundcards for output, too. See also What are all these mixers? (Matthias)

First, obtain a list of supported lines either from a Mixer object or from AudioSystem. For this, use the methods getSourceLineInfo() and getTargetLineInfo(). Then, check each of the returned Line.Info objects if it is an instance of DataLine.Info. If it is, cast the object to DataLine.Info. Now you can call getFormats() to obtain the AudioFormat types supported by this line type.

A code example:

Line.Info[] infos = AudioSystem.getSourceLineInfo();
// or:
// Line.Info[] infos = AudioSystem.getTargetLineInfo();
for (int i = 0; i < infos.length; i++)
{
  if (infos[i] instanceof DataLine.Info)
  {
    DataLine.Info dataLineInfo = (DataLine.Info) infos[i];
    AudioFormat[] supportedFormats = dataLineInfo.getFormats();
  }
}

To see what is supported on your system, you can use the application jsinfo. See also Why are there AudioFormat objects with frame rate/sample rate reported as -1 when I query a Mixer for its supported formats? (Matthias)

It depends on the hardware. The mixers just report formats that are supported by the device driver. Typically, there are between 8 and 20 supported formats. To write a portable application, you should not assume that a certain format is always supported (though in fact, 44.1 kHz 16 bit stereo is almost always supported). Rather, you should check the supported formats at run-time and try to convert your audio data to one of the available formats. See also How can I obtain the formats supported by a mixer (or at all)? (Matthias)

The -1 (AudioSystem.NOT_SPECIFIED) means that any reasonable sample rate is supported. Common soundcards typically support sample rates between 4 kHz and 48 kHz. See also How can I obtain the formats supported by a mixer (or at all)? (Matthias)

There is no really satisfying solution. You can try to match the name in the Mixer.Info object of a Port Mixer against the one of a DataLine Mixer. On Linux, this is reliable by looking at the device id that is part of the mixer name: "(hw:0)", "(hw:1)", "(plughw:0,1)". The first (or only) number refers to the number of the soundcard.

Windows don't allow to query which port belongs to which soundcard (there are ways on Windows, but it was not possible to use them for Java Sound because they require actually opening the devices). So the only thing you can do is to match the name of the soundcard. However, this will not always work reliably. Especially, if there are two soundcards of the same model, their names will look the same.

See also What are all these mixers? (Matthias)

You can detect the mixer implementation from the class types of the lines you get:

See also What are all these mixers? and How can I find out which soundcard driver is used? (Matthias)

In the JDK 1.5.0, the "Direct Audio Device" mixers are used by default if they support more than one concurrently active SourceDataLine. This is the case if either the soundcard hardware supports mixing of multiple channels (and the driver supports it) or the driver does software mixing of multiple channels.

If this is not the case, the "Java Sound Audio Engine" is used by default. If you don't mind the limitation that there will be only one SourceDataLine or Clip instance, you can still use the "Direct Audio Device" mixers by addressing them directly (see How can I get a Line from a specific Mixer?).

See also Can I make ALSA the default in version 1.4.2? and How can I enable mixing with the "Direct Audio Device" mixers on Linux? (Matthias)

See also What are all these mixers? and Q: 3.5 (Matthias)

First, check which mixer is used (see How can I find out which Mixer implementation is used?). Then consult the table in Which soundcard drivers can be used by Java Sound? to find out the driver.

For Linux, there is no way to tell from Java Sound if a real OSS driver or ALSA's OSS emulation is used. See also How can I find out which soundcard driver is installed on my Linux system? (Matthias)

In 1.4.2, the "Java Sound Audio Engine" is still the default. To use the ALSA support, you have to obtain the Mixer object representing the direct audio access. Then, obtain lines from this object instead of via AudioSystem. See also How can I get a Line from a specific Mixer? (Matthias)

You can, but only with an ugly trick: rename, remove or disable the device files /dev/dsp*. This disables the Java Sound Audio Engine, so the JDK falls back to use the ALSA mixers. But be aware that this disables the software synthesizer ("Java Sound Synthesizer"), too. So you won't be able to play MIDI files. And of course native applications using /dev/dsp won't be happy, too. (Matthias)

The "Direct Audio Device" implementation on Linux is based on ALSA. Mixing is available in the Mixer instance if ALSA provides mixing. This is the case if the soundcard can do mixing in hardware and its ALSA driver supports this feature. This is true for some common soundcards like Soundblaster LIFE! and Soundblaster Audigy and cards based on the Trident 4D Wave NX chipset. If this feature is available at all, it needs no special configuration. It is enabled by default.

Using ALSA's dmix plug-in does not work together with Java Sound. The reason is that the "Direct Audio Device" mixer implementation based on ALSA queries the available hardware devices. However, a dmix device in ALSA is no hardware device, so it is not recognized. Discussions about this issue led to the conclusion that there is no easy way to integrate a query for additional devices.

See also Q: 3.4 (Matthias)

According to Florian:

(Matthias)

Run /sbin/lsmod to show the currently loaded kernel modules. If there are entries "snd" and "snd-*", you are running ALSA. A typical picture of ALSA is like this:

snd-mixer-oss          12672   1 (autoclean) [snd-pcm-oss]
snd-seq                38348   0 (autoclean) (unused)
snd-emu10k1            65956   1 (autoclean)
snd-hwdep               5024   0 (autoclean) [snd-emu10k1]
snd-rawmidi            13792   0 (autoclean) [snd-emu10k1]
snd-pcm                64416   0 (autoclean) [snd-pcm-oss snd-emu10k1]
snd-page-alloc          6148   0 (autoclean) [snd-emu10k1 snd-pcm]
snd-timer              15040   0 (autoclean) [snd-seq snd-pcm]
snd-ac97-codec         42200   0 (autoclean) [snd-emu10k1]
snd-seq-device          4116   0 (autoclean) [snd-seq snd-emu10k1 snd-rawmidi]
snd-util-mem            1504   0 (autoclean) [snd-emu10k1]
snd                    36832   0 (autoclean) [snd-pcm-oss snd-mixer-oss snd-seq
snd-emu10k1 snd-hwdep snd-rawmidi snd-pcm snd-timer snd-ac97-codec
snd-seq-device snd-util-mem]
soundcore               3556   6 (autoclean) [snd]
		  

An alternative way it to look for the directory /proc/asound/. It is only present if ALSA is active. (Matthias)

Internally, Java Sound implementations usually do not work with hardware buffers. Instead, they use the platform's audio API for accessing the soundcard. See also DataLine buffers (Matthias)

The synchronization functions in Mixer are not implemented. Nevertheless, playback typically stays in sync. (Matthias)

As with multiple playback lines from the same Mixer object, playback and recording lines from the same Mixer object stay in sync once they are started. In practice, this means that you can achieve synchronization this easy way only by using the "Direct Audio Device" mixers. Since the "Java Sound Audio Engine" only provides playback lines, but no recording lines, playback/recording sync is not as easy with the "Java Sound Audio Engine". See also How can I synchronize two or more playback lines?

If playback and recording lines originate from different Mixer objects, you need to synchronize the soundcards that are represented by the Mixer objects. So the situation is similar to external synchronization. See also How can I synchronize playback to an external clock?

(Matthias)

This is possible in one of two ways:

See also Q: 3.12 (Matthias)

Yes. There is no mechanism in Java Sound to start Clip instances synchronuously. However, calling start() for all Clip instances in a loop with the Clip instances otherwise prepared should be precise enough. Once started, Clip instances played on the same Mixer instance should stay in sync. If they don't, make sure they have the exactly same length. Clip instances played on different Mixer instance are likely to drift away from each other, unless the soundcard clocks are synchronized (which is only possible on "pro" soundcards). (Matthias)

The reason of this problem is clock drift. There are two clocks involved in this scenario: The real time clock is used to measure the period of time you are recording or playing. The soundcard clock determine how many samples are recorded or played during this period. Since there are two different hardware devices, the inherently drift away from each other over time.

There are several ways to deal with this problem:

(Matthias)

Synchronization isn't implemented in any known Java Sound implementation. It may be implemented in future versions. Note that you can check the availability of synchronization with the method Mixer.isSynchronizationSupported(). See also Do multiple Clip instances that are looped stay in sync?, How can I synchronize two or more playback lines? and Why does recording or playing for a certain period of time results in audio data that is shorter or longer than the period I recorded / played? (Matthias)

Have a look at the Java Sound Resources: Examples. (Florian)

The Java Sound API does not support this currently. Future versions are likely to, because this is indeed quite important. For the moment, you will need to implement your own class for writing .wav or .aiff files. Or make meaningful filenames... (Florian)