Hi,
Is there anyone using Pd for doing intense file streaming towards an Shoutcast/Icecast server? I am interesting in hearing impressions, discovered drawbacks, etc..
** Some background **
Being in need to prepare a machine running an Icecast source client 24/7, I've been shopping around the last few days.
All existing applications I've tried are either,
- Play list oriented (as seen in many, many Internet radio solutions)
They are designed to randomly select songs from a huge database containing millions of files. Enabling the user to program discipline in songs to pick with quite a flexibility... where as, I only need to schedule recorded programs to play at certain hours. The timing that things get played is as important as what gets played.
or
- Has no ability to adjust volume.
I am expecting to face occasions where I need volume control over the output to create fades. (Not "cross", just simple fade outs) MPD (Music Player Daemon) came soooo close, assuming I'd be writing the scheduler myself. Unfortunately its volume control affects only local the output, not volumes of streams sent to Icecast severs.
As much as I love playing with Pd, I never thought at fist that it may be the only application that would fulfill all my needs in one app, opposed to preparing some obscure Jack networks.
So,... back to initial statement.
Thanks.
-- David Shimamoto
I've had success with nSlam: http://tot.sat.qc.ca/down_nslam.html
There is, in fact, in the package, a prepackaged example of streaming application. I have not streamed 24/7 but for about 4 hours without a problem. I used to run many different patches 24/7 (in different contexts) without pd crashing so I would expect it to work longterm as well.
Let us know how it works out for you, please.
./MiS
On Thu, Nov 27, 2008 at 12:05 AM, PSPunch shima@pspunch.com wrote:
Hi,
Is there anyone using Pd for doing intense file streaming towards an Shoutcast/Icecast server? I am interesting in hearing impressions, discovered drawbacks, etc..
** Some background **
Being in need to prepare a machine running an Icecast source client 24/7, I've been shopping around the last few days.
All existing applications I've tried are either,
- Play list oriented (as seen in many, many Internet radio solutions)
They are designed to randomly select songs from a huge database containing millions of files. Enabling the user to program discipline in songs to pick with quite a flexibility... where as, I only need to schedule recorded programs to play at certain hours. The timing that things get played is as important as what gets played.
or
- Has no ability to adjust volume.
I am expecting to face occasions where I need volume control over the output to create fades. (Not "cross", just simple fade outs) MPD (Music Player Daemon) came soooo close, assuming I'd be writing the scheduler myself. Unfortunately its volume control affects only local the output, not volumes of streams sent to Icecast severs.
As much as I love playing with Pd, I never thought at fist that it may be the only application that would fulfill all my needs in one app, opposed to preparing some obscure Jack networks.
So,... back to initial statement.
Thanks.
-- David Shimamoto
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Michael,
First of all, after a look at nSlam, overwhelmed by its features and refreshing my mind on a cup of coffee, I've found a solution using MPD.. there actually was a way to assign its only volume control to my desired output.
Anyway, I've taken a brief look at the documents and what I think is the example you mentioned (StreamCaster?).
The concepts in the suite is certainly inspiring in terms of making practical applications based on Pd. For my current project, I am trying to go low cost on hardware as much as possible, so I think I will stick with MPD for now. I hear people run it on 75MHz Pentiums. I am considering utilizing a NAS running Linux at 200MHz or so and only has a CLI.
Thanks anyway. I will take a closer look at it today.
-- David Shimamoto
I've had success with nSlam: http://tot.sat.qc.ca/down_nslam.html
There is, in fact, in the package, a prepackaged example of streaming application. I have not streamed 24/7 but for about 4 hours without a problem. I used to run many different patches 24/7 (in different contexts) without pd crashing so I would expect it to work longterm as well.
Let us know how it works out for you, please.
./MiS
On Thu, Nov 27, 2008 at 12:05 AM, PSPunch shima@pspunch.com wrote:
Hi,
Is there anyone using Pd for doing intense file streaming towards an Shoutcast/Icecast server? I am interesting in hearing impressions, discovered drawbacks, etc..
** Some background **
Being in need to prepare a machine running an Icecast source client 24/7, I've been shopping around the last few days.
All existing applications I've tried are either,
- Play list oriented (as seen in many, many Internet radio solutions)
They are designed to randomly select songs from a huge database containing millions of files. Enabling the user to program discipline in songs to pick with quite a flexibility... where as, I only need to schedule recorded programs to play at certain hours. The timing that things get played is as important as what gets played.
or
- Has no ability to adjust volume.
I am expecting to face occasions where I need volume control over the output to create fades. (Not "cross", just simple fade outs) MPD (Music Player Daemon) came soooo close, assuming I'd be writing the scheduler myself. Unfortunately its volume control affects only local the output, not volumes of streams sent to Icecast severs.
As much as I love playing with Pd, I never thought at fist that it may be the only application that would fulfill all my needs in one app, opposed to preparing some obscure Jack networks.
So,... back to initial statement.
Thanks.
-- David Shimamoto
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2008-11-27 at 14:05 +0900, PSPunch wrote:
Hi,
Is there anyone using Pd for doing intense file streaming towards an Shoutcast/Icecast server? I am interesting in hearing impressions, discovered drawbacks, etc..
http://www.netpd.org/netpd.m3u http://www.radiosolarkompass.org/listen.pls
both are automatically generated streams, where pd is doing the logic, volume control and the actual streaming to the icecast server. i wouldn't call them very stable, but this is probably more due to some hacks, that were necessary to make it running and due to my freestyle programming style of that time. they are both running 24/7, to be honest 'pseudo 24/7', since cron executes a killall/startall script every night, so that in case of crash the off-air time is not longer than a day (i don't want to check them every day).
i wonder, how it would be to have pure generative stream without mplayer->jackd->pd quirks. i could imagine, that it would run quite stable.
i guess, depending on what you are doing, you would need to restart pd anyway from time to time (-> symbol table pollution). but this applies to long-term uses of pd generally, not only to streaming.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi Roman,
Thanks for the insight. Very interesting..
By the way,
i wonder, how it would be to have pure generative stream without mplayer->jackd->pd quirks. i could imagine, that it would run quite stable.
Is this how you got your chain running? If so, is there a reason you avoided using file playback objects within Pd?
-- David Shimamoto
On Fri, 2008-11-28 at 09:11 +0900, PSPunch wrote:
Hi Roman,
Thanks for the insight. Very interesting..
By the way,
i wonder, how it would be to have pure generative stream without mplayer->jackd->pd quirks. i could imagine, that it would run quite stable.
Is this how you got your chain running? If so, is there a reason you avoided using file playback objects within Pd?
nono... it's only, that i am not even using pd to playback the sound, but mplayer piping the sound over jackd to pd. pd starts mplayer instances with appropriate flags through [shell], so that mplayer instances connect to pd on individual jack ports. the problem with that approach: sometimes mplayer hangs, which makes whole pd hang or at least impossible from within pd to stop mplayer. a typical situation is: mplayer can connect, but stream buffer is not filled and as long as it is waiting, you cannot send commands to mplayer, thus also no stop commands, so you have to kill it through another [shell] -> this sometimes kills not only mplayer, but the whole pd process. working without [shell] mess seems to me much more stable.
the reason why i use mplayer for the playback - and not pd - is because it supports basically any audio format you can think of. that was an important goal for the radiosolarkompass project.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Michal Seta -
PSPunch -
Roman Haefeli