-
Enhancement
-
Resolution: Not an Issue
-
P5
-
None
-
1.0
-
generic
-
generic
From: Jarno van Rooyen <###@###.###>
To: "'Kara Kytle'" <Kara.Kytle@Eng>
Subject: RE: [javasound] manipulating audio data
Date: Wed, 13 Jan 1999 11:22:07 +0200
MIME-Version: 1.0
...
I would think that the PullAudioOutput should only support the native
formats that the SystemDevice/hardware to which it is connected can support.
That way one ensures that the computer will spend no more time processing
audio samples ( except from delivering it to the audio hardware ). I would
consider supporting PCM and u-law as a wide range of options at this point
of media flow. If the hardware does not support u-law, I do not think that
it is a good idea to let the PullAudioOutput accept u-law samples. I also
note that there is no mechanism to obtain a list of supported formats from
the PullAudioOutput, but one may only query it whether it accepts a certain
format.
I presume that all the supported sample rates of the hardware will be
accepted. ( My Creative SoundBlaster box boasts "User-selectable sample
rates from kHz to 44.1 kHz" ). In general I try to avoid sample rate
converters. Properly designed converters results in delays and bad
converters sounds terrible and does a lot of damage to speech recognition
efforts.
...
Here is my suggestion. Design a framework for audio format conversion. It
does not have to be part of either JavaSound or JMF. Supply a few format
converters (codecs) and leave the rest to 3rd party developers. Such a
framework must allow for the installation and removal of codecs using some
form of naming scheme. With this framework in place it should be possible to
connect any PullMediaSource to any PullAudioOutput through a chain of
codecs. It must still be possible to disable this automatic mapping of
formats on a per connection basis.
General audio effects processing can probably occur after the format
conversion. I've not read through the new JMF docs in detail, but I'm aware
of some sort of processing architecture. A generalized form of such an
architecture with no limitations to the number and arrangement of processors
would be nice. This though seems to belong to the JMF realm of things.
...
Jarno van Rooyen
DataFusion Systems
To: "'Kara Kytle'" <Kara.Kytle@Eng>
Subject: RE: [javasound] manipulating audio data
Date: Wed, 13 Jan 1999 11:22:07 +0200
MIME-Version: 1.0
...
I would think that the PullAudioOutput should only support the native
formats that the SystemDevice/hardware to which it is connected can support.
That way one ensures that the computer will spend no more time processing
audio samples ( except from delivering it to the audio hardware ). I would
consider supporting PCM and u-law as a wide range of options at this point
of media flow. If the hardware does not support u-law, I do not think that
it is a good idea to let the PullAudioOutput accept u-law samples. I also
note that there is no mechanism to obtain a list of supported formats from
the PullAudioOutput, but one may only query it whether it accepts a certain
format.
I presume that all the supported sample rates of the hardware will be
accepted. ( My Creative SoundBlaster box boasts "User-selectable sample
rates from kHz to 44.1 kHz" ). In general I try to avoid sample rate
converters. Properly designed converters results in delays and bad
converters sounds terrible and does a lot of damage to speech recognition
efforts.
...
Here is my suggestion. Design a framework for audio format conversion. It
does not have to be part of either JavaSound or JMF. Supply a few format
converters (codecs) and leave the rest to 3rd party developers. Such a
framework must allow for the installation and removal of codecs using some
form of naming scheme. With this framework in place it should be possible to
connect any PullMediaSource to any PullAudioOutput through a chain of
codecs. It must still be possible to disable this automatic mapping of
formats on a per connection basis.
General audio effects processing can probably occur after the format
conversion. I've not read through the new JMF docs in detail, but I'm aware
of some sort of processing architecture. A generalized form of such an
architecture with no limitations to the number and arrangement of processors
would be nice. This though seems to belong to the JMF realm of things.
...
Jarno van Rooyen
DataFusion Systems
- relates to
-
JDK-4204111 Request simple, exposed transport model for data to and from Java Sound
-
- Closed
-