Pd-extended mp3amp~ crashes

I received my Organelle M yesterday and already I’m back to being a computer developer rather than a musician… oh well.

So here’s my conundrum. One of my favorite materials to work with are live internet radio streams. I’m trying to use [mp3amp~] from the pd-extended/unauthorized external. However, it crashes as soon as DSP is flipped on.

There’s a Pd forum discussion here: mp3amp~ causing Pd to crash when open with DSP on | PURE DATA forum~

So I went to try to recompile it from scratch. But then discovered that the Organelle does not have a package manager installed, so getting lmp3lame-dev installed required me to compile THAT from scratch. Which was actually painless.

But now I’m faced with trying to get mp3amp~ itself compiled, and I’m running into issues. And I don’t even know if it’s going to work. There are complexities in the Makefile that don’t really let me compile just the one external successfully; and to compile the entire thing requires that I have the speex lib available, which was a dependency nightmare (to compile that from scratch require Meson and Ninja).

Any advice or help would be greatly appreciated, I think that this external would be of general interest to many Organellistes. I was never very good at compiling things, as I never studied C and am from a generation spoilt by package managers.

1 Like

I think I actually ran into this issue years ago when I first started working with the internet streams, and compromised by cobbling together a handful of OGG streams and using pdogg/oggamp~ instead.

Indeed, as consolation for today’s failures, ONE of the OGG streams I used in my original project still works (http://stream.xaok.org:8000/frs.ogg)

There’s a broader discussion to be had about why (the patented) mp3 stream has won out over open-source ogg; why radio stations are pulling their OGG streams (WFMU, for example); and why so many are moving to Mixcloud instead (which basically breaks a lot of what makes radio/internet radio so much fun).

3 Likes

I tried looking for the mp3cast~ external and had no luck tracking it down. I couldn’t find the source or anything either but I don’t know how much help I could be either since I have limited C skills too. If you could post some of your work, I’ll see if I can bang my head against the keyboard enough to be helpful tho. If you are thinking of going the oggamp route, C&G has compiled an external for the Organelle.

I am in fact already successfully using the pdogg/oggamp~ external as compiled by C&G, so no real issues there (except that it is fussy about disconnecting and reconnecting).

The mp3cast~ external is under the pd-extended/unauthorized directory of the same pd-extended collection. [as I note in another post I actually care about mp3AMP~, but I keep accidentally typing “mp3CAST~” and I’m trying to edit my posts… sorry!]

The C&G Organelle binaries are at Organelle_pd_extra/pd-extended/unauthorized at master · critterandguitari/Organelle_pd_extra · GitHub

The source code for it is at https://puredata.info/downloads/unauthorized (the link to actually download it is Download Pure Data Computer Music System from SourceForge.net)

I assume this would be child’s play for anybody with any gcc/make skills whatsoever. Given the limitations of the stock Organelle w/r/t a package manager especially, cross-compiling on a different machine is probably indicated.

Oh! Also, be aware that I edited my posts because I keep mixing up mp3cast~ and mp3amp~: the one I care about is “amp”, the one that is a client for playing back mp3 streams . I don’t know if mp3cast~ (for publishing mp3 streams) works well or not, but it would of course be useful to know if it does.

I’ll see if I can take a crack at it. Also if your oggamp module is in a state where it could be released, I would love to take a look at it

I’m working on it! It’s pretty straightforward to use oggamp~ in itself, so I’m essentially just trying to figure out a good interface for it.

I’m thinking that one would just provide a simple text file with a list of ogg stream urls that would be shared across all slotted instances of the module. Each module could “tune” to one of these urls at a time.

The only thing that is posing a challenge, or is an open question at this time, is how to override what orac shows on the display, since there is no “string” or “symbol” data type (that I’m aware of) in orac’s configuration setup. I’ll do some experimenting, as I’m just becoming familiar with both orac and organelle’s API.

Ideally, I’d like to have some way to have a unique configuration of urls for each module instance, but that’s not really the focus of orac. It would be akin to shared sample kits, but for text files.

There is no data/string type that is readily available. If you check out a lot of the recent modules I have put out (OracLoops, Loopy, Samplekids, and Converb) they all pull a file path using an abstraction called soundshare.

You could probably have a random number generator choose to pull a random one into a textfile object and then tune it with a float object with a 0 to 1 boundary

Currently I’m using an “int” type and splitting out a text file that way. The display shows “Station 0” (for example), which also requires hard-coding a range that at least encompasses the number of url entries in the text file.

Using a float and some rounding, I could make it a bit more flexible. But if you’re already providing a hard-coded list of urls anyway, it doesn’t really make too much sense to fuss.

Ideally, I’d love to see a “symbol” or even “list” type for the orac module configuration.

1 Like

In my PD ignorance the first thing I’d try in this case would be to put mp3amp~ in its own pd~ subprocess and try to run the instance with some flags especially the “compatibility” flag, but I’d also experiment with audio buffer etc…

Give it a try! :slightly_smiling_face:

2 Likes

Tried in a sub-process with lower versions, same issues.

Successfully compiled Yves Degoyon’s (the original author) own non-free version. However, it crashed in new and different ways!

Apparently implementing and maintaining a streaming MP3 decoder is not easy.

I’m wondering if maybe I can use an up-to-date command-line program via ggee/shell and pipe the audio into Pd.

Thoughts?

The only way I’ve been able to stream mp3 into Pd is by using mplayer to open the stream and then connecting the output to Pd input using jack (audio server for connecting different audio apps). So the process is a little different from a default Organelle Pd patch, which doesn’t use jack (Pd is just connected right to the audio hardware).

You can override the default behavior by including a run.sh file in your patch folder, instead of a main.pd. When you start the patch from the Organelle, it will execute run.sh instead of starting Pd. Then in run.sh you can run the commands to open mplayer, start Pd and connect things up. Here is an example of run.sh that seemed to work:

killall mplayer
killall jackd
sleep 2
/usr/bin/jackd -dalsa -dhw:audioinjectorpi,0 -r44100 -p1024 -n2 &
mplayer -ao jack:noconnect:name=radio http://wprb.streamguys1.com/live &
pd -jack -nojackconnect ~/fw_dir/mother.pd radio.pd &
sleep 4
jack_connect radio:out_0 pure_data:input0
jack_connect radio:out_1 pure_data:input1
jack_connect pure_data:output0 system:playback_1
jack_connect pure_data:output1 system:playback_2

In my notes I also have this one which is a bit simpler but does the same thing:

killall mplayer
killall jackd
sleep 1
/usr/bin/jackd -dalsa -dhw:audioinjectorpi,0 -r44100 -p1024 -n2 &
sleep 1
pd -nogui -jack  ~/fw_dir/mother.pd radio.pd &
sleep 1
mplayer -ao jack:port=pure_data:name=radio http://wprb.streamguys1.com/live &

(you might need to install mplayer and/or jack)

In the patch radio.pd (also in the patch folder) you can do whatever with the stream using [r~ inL] and [r~ inR]. It was pretty fun proof of concept, but would be great to get it working in a more general sense, like globally selecting streaming audio as the audio input.

2 Likes

I did some debugging and it seems (for me) that mp3amp~ is crashing with a Segmentation Fault when it calls the external decode_header() function, which appears to be part of mpg123 (inside libmp3lame?).

My best guess (after looking at the current mpg123 source code) is that the struct used in that call is defined in mp3amp~ against an older version of mpg123, so decode_header is trying to write to invalid memory locations.

Next thing I would try would be to see if it is possible to install an older build of libmp3lame on the Organelle, or re-implement decode_header.

But of course there could be further problems down the line. This is all probably a dead end. But just wanted to share this here in case some brave person is looking for info in the future.

2 Likes

OK, so a more up-to-date effort here looks promising: ffplay~ - An implementation of FFmpeg for audio playback of almost any media format | PURE DATA forum~

And the repo: GitHub - myQwil/pd-quilt: Externals I've made for pure data

Further into the thread, somebody posts a version they compiled for a Pi 3. I tried it and it doesn’t work out of the box: a bunch of .so files are off by like, one number. I don’t understand much about .so files and linking, etc, but I tried and failed to compile it directly on the Organelle.

I’m a bit short on time at the moment, but next time I get a chance to try, I’ll update this thread. Perhaps somebody else will beat me to it and get it compiled for the Organelle??

2 Likes

It looks like the [ffplay~] was failing to compile because the version of ffmpeg in the Organelle M’s repo is quite old. I’m compiling the latest version to see if it goes… could be going for a while though, lol.

Keep your fingers crossed. Looks like a really powerful, long-term solution to many format playback tasks in Pd

2 Likes