Icecast dev - Aug 2004 - [Interopcast-general] about translatingdocumentation, but not only documentation.

Just a few weeks ago, I was thinking of writing a streaming source using 
libshout and portaudio. I was also considering LADSPA support, to do 
some minor post-processing before encoding. However, I'm currently 
developing on Mac OS X, and LADSPA's shared library plugin model has 
some issues here to be resolved.

Another nice feature I have given a thought on is incorporating 
AudioCompress, a pretty nice volume normalizer which can be found at 
<http://trikuare.cx/code/AudioCompress.html>, originally an XMMS plugin. 
I often find myself feeding the encoder computer with a colder line 
input to prevent clipping but want to produce a hotter encoded stream. 
This feature would be nice to have.

Before I saw this advice of adding PortAudio to IceS, I was going to 
begin implementing these ideas as a new project, tentatively called 
"PortStreamer." I'm quite enthusiastic about this eye catching
project
name, but I'm also open to the possibility of dropping this project in 
favor of enhacing IceS instead.

Comments or suggestions?

liulk

Lee Azzarello wrote:
>I think if Ices could incorporate PortAudio it would handle some serious
>portability issues.
>
>  
>
<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Ices is pretty stable for many uses, I would save the time and look into
adding PortAudio support to it. Karl H has a version not in CVS that
impliments callbacks, if I understand it correctly.

Also, there is no common plugin API that's cross platform. But there is no
doubt that Ices needs plugin support for basic things like
compression/limiting and EQ. I would recommend setting up a build
environment that uses the platform's native plugin API, for example LADSPA
for Linux and AudioUnits for OS X. Then the build script would detect the
platform and link to the right library. This is what a program called
Audacity does for it's plugins support, although it doesn't do
AudioUnits
in OS X yet.

I used to be involved with OS X audio development but have since moved to
Linux, so I'm not too up to date with OS X software.

-l[e^2]
------------------------------
http://www.fallingforward.net/
people experimenting with music, art and technology

On Sun, 3 Aug 2003, Likai Liu wrote:
> Just a few weeks ago, I was thinking of writing a streaming source using
> libshout and portaudio. I was also considering LADSPA support, to do
> some minor post-processing before encoding. However, I'm currently
> developing on Mac OS X, and LADSPA's shared library plugin model has
> some issues here to be resolved.
>
> Another nice feature I have given a thought on is incorporating
> AudioCompress, a pretty nice volume normalizer which can be found at
> <http://trikuare.cx/code/AudioCompress.html>, originally an XMMS
plugin.
> I often find myself feeding the encoder computer with a colder line
> input to prevent clipping but want to produce a hotter encoded stream.
> This feature would be nice to have.
>
> Before I saw this advice of adding PortAudio to IceS, I was going to
> begin implementing these ideas as a new project, tentatively called
> "PortStreamer." I'm quite enthusiastic about this eye
catching project
> name, but I'm also open to the possibility of dropping this project in
> favor of enhacing IceS instead.
>
> Comments or suggestions?
>
> liulk
>
> Lee Azzarello wrote:
>
> >I think if Ices could incorporate PortAudio it would handle some
serious
> >portability issues.
> >
> >
> >
>
>
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> icecast project homepage: http://www.icecast.org/
> To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is
needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
>
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Monday 04 August 2003 12:30, Likai Liu wrote:
> Just a few weeks ago, I was thinking of writing a streaming source using
> libshout and portaudio. I was also considering LADSPA support, to do
> some minor post-processing before encoding. However, I'm currently
> developing on Mac OS X, and LADSPA's shared library plugin model has
> some issues here to be resolved.
>
> Another nice feature I have given a thought on is incorporating
> AudioCompress, a pretty nice volume normalizer which can be found at
> <http://trikuare.cx/code/AudioCompress.html>, originally an XMMS
plugin.
> I often find myself feeding the encoder computer with a colder line
> input to prevent clipping but want to produce a hotter encoded stream.
> This feature would be nice to have.
>
> Before I saw this advice of adding PortAudio to IceS, I was going to
> begin implementing these ideas as a new project, tentatively called
> "PortStreamer." I'm quite enthusiastic about this eye
catching project
> name, but I'm also open to the possibility of dropping this project in
> favor of enhacing IceS instead.
>
> Comments or suggestions?
I don't particularly want to add another mandatory dependency to ices2, but
we
could do it optionally (as all the audio-input modules currently are, so this 
is just adding a new one, and keeping the old ones for systems where they 
work). This just requires a little bit of autoconf trickery to get right.

If you want to add portaudio support to ices in this way, that would be 
excellent - I look forward to getting a patch from you!

I'm less sure about 'audiocompress'. Perhaps a general-purpose
(possibly using
LADSPA, or something else) audio-manipulation pipeline, to which 
AudioCompress could be one option? 

<p>Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Mon, 4 Aug 2003, Michael Smith wrote:
> I'm less sure about 'audiocompress'. Perhaps a general-purpose
(possibly using
> LADSPA, or something else) audio-manipulation pipeline, to which
> AudioCompress could be one option?
Though it is very Linux specific, I would /highly/ recommend JACK, a
low-latency audio server that allows interapplication audio patching. I
use JACK for all routing on my desktop system at home and it's working
great.

An example of a scenario:

input from the sound card is patched to jack-rack, which is hosting a
LADSPA plugin chain of EQ, compression and limiting. Then it's patched to
both ices and a peak meter to send the source to the server and visually
monitor the output signal.

JACK is very powerfull. http://jackit.sourceforge.net/

-l[e^2]
------------------------------
http://www.fallingforward.net/
people experimenting with music, art and technology

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Michael Smith wrote:
>I'm less sure about 'audiocompress'. Perhaps a general-purpose
(possibly using
>LADSPA, or something else) audio-manipulation pipeline, to which 
>AudioCompress could be one option? 
>  
>
I agree that it would have been better to have audiocompress ported as 
an LADSPA plugin. My initial impression after taking look at their 
source code is that it shouldn't be so much of a trouble other than 
fulfilling LADSPA's formals. But what is stopping me at this moment is 
exactly the problem with dlfn on Mac OS X.

There are two paths towards PortAudio integration. One is to directly 
modify im_oss.c to use the PABLIO (blocking I/O subset of PortAudio) and 
forget about callbacks. This is the easiest method but has the 
disadvantage that the same audio buffer is copied perhaps at least 2-3 
times. The second one is to rewrite IceS based on callbacks, or perhaps, 
based entirely on PortAudio, so we don't have to worry about supporting 
different sound I/O APIs -- this option is probably quite controversial.

I've heard of JACK support on PortAudio, though the recent stable V18.1 
release still doesn't have it. Another problem with PortAudio is that, 
as of V18.1, supports only one host sound I/O method per compilation. 
This means the user can't select which sound I/O to use, should more 
than one is available, other than the one that is compiled in. V19 will 
remedy these issues altogether. It seems wise to wait for PortAudio V19 
to become a stable release.

liulk

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.