Hi friends
I was surfing the web looking for some reports of jumper pin 3 and 4 of the PT2399 (my sea urchin sometimes stop the delay... and yes in my case it solved the issue..so far) and found a post on dsb that reports a supposed solution for the usual noise of the 2399
I would like to ask to you guys read it and make your comments..
"So, I was running through ideas on the Little Angel thread HERE and going through the new data from Merlin and it dawned on me...
On the Datasheets, there are only 2 ends terminating to digital grounds. Merlin made note that the Pin 4 "Digital Ground" can be left unconnected, because it is already connected to analog ground through a 10 ohm resistor.
So, I have tried this on a Little Angel, and my noise pig Sewer Pipes Ringverb. I could not get the SP to shut up, no way, no how.
All we gotta start doing is connecting the delay resistor between Pins 6 and 4. That's it. No more "SSHhhhh" until the signal dies out. Awesome stuff!!!
Anyone else want to confirm this for me? I have quiet PT effects, finally! It's too sweet.
frequencycentral:
$h!t yeah!
Looking at the PT2399 datasheet, the delay resistor is actually connected to digital ground, not analogue ground. How have we all missed this crucial peice of information for so many years?
Genius David!
If this is as good as it sounds I'm amazed, excited and in awe!
WhenBoredomPeaks:
I am thinking about how to realise this on my Tonepad Rebote 2.5 pcb without too much destruction.
edit: it looks like that i should cut the connection right between the legs 3-4 and probably should ground that 47uf cap from leg 2 to an analog ground.
Earthscum:
yep, apparently the delay resistor just gets connected straight to pin 4 from 6. I'm still using LA Ver1 with 10n integrating caps and 1n filter caps, and it's still a bit hissy, but it's the regular hiss (may be getting most from the 5532, got an hour or 2 before I have to load stuff up for a show, so I'm gonna check it out now). I did no other mods to the circuits, and was about to start digging for tants, rewiring grounds, etc, bigger caps, and thought about this. So, I do believe this may be the final cure-all for the noise issue. I'm stoked to really start putting some pain to sound with these now... and I can realize my new project (noise was going to be the biggest issue, running harmonics only through delay).
I bet James' (anchovie)Noise Ensemble would even sound "GREAT" with this fix!
ETA: Yep... 100p across the 470k feedback took off the top hiss in the LA... now I think the last bit of digi noise I have is from the Vref. It's just slight clock noise I can hear now that the hiss is gone"
here is the link for that post
http://www.diystompboxes.com/smfforum/index.php?topic=92515.0;wap2 (http://www.diystompboxes.com/smfforum/index.php?topic=92515.0;wap2)
Quote from: gtangas on March 28, 2013, 12:12:53 AM
Hi friends
I was surfing the web looking for some reports of jumper pin 3 and 4 of the PT2399 (my sea urchin sometimes stop the delay... and yes in my case it solved the issue..so far) and found a post on dsb that reports a supposed solution for the usual noise of the 2399
I would like to ask to you guys read it and make your comments..
"So, I was running through ideas on the Little Angel thread HERE and going through the new data from Merlin and it dawned on me...
On the Datasheets, there are only 2 ends terminating to digital grounds. Merlin made note that the Pin 4 "Digital Ground" can be left unconnected, because it is already connected to analog ground through a 10 ohm resistor.
So, I have tried this on a Little Angel, and my noise pig Sewer Pipes Ringverb. I could not get the SP to shut up, no way, no how.
All we gotta start doing is connecting the delay resistor between Pins 6 and 4. That's it. No more "SSHhhhh" until the signal dies out. Awesome stuff!!!
Anyone else want to confirm this for me? I have quiet PT effects, finally! It's too sweet.
frequencycentral:
$h!t yeah!
Looking at the PT2399 datasheet, the delay resistor is actually connected to digital ground, not analogue ground. How have we all missed this crucial peice of information for so many years?
Genius David!
If this is as good as it sounds I'm amazed, excited and in awe!
WhenBoredomPeaks:
I am thinking about how to realise this on my Tonepad Rebote 2.5 pcb without too much destruction.
edit: it looks like that i should cut the connection right between the legs 3-4 and probably should ground that 47uf cap from leg 2 to an analog ground.
Earthscum:
yep, apparently the delay resistor just gets connected straight to pin 4 from 6. I'm still using LA Ver1 with 10n integrating caps and 1n filter caps, and it's still a bit hissy, but it's the regular hiss (may be getting most from the 5532, got an hour or 2 before I have to load stuff up for a show, so I'm gonna check it out now). I did no other mods to the circuits, and was about to start digging for tants, rewiring grounds, etc, bigger caps, and thought about this. So, I do believe this may be the final cure-all for the noise issue. I'm stoked to really start putting some pain to sound with these now... and I can realize my new project (noise was going to be the biggest issue, running harmonics only through delay).
I bet James' (anchovie)Noise Ensemble would even sound "GREAT" with this fix!
ETA: Yep... 100p across the 470k feedback took off the top hiss in the LA... now I think the last bit of digi noise I have is from the Vref. It's just slight clock noise I can hear now that the hiss is gone"
here is the link for that post
http://www.diystompboxes.com/smfforum/index.php?topic=92515.0;wap2 (http://www.diystompboxes.com/smfforum/index.php?topic=92515.0;wap2)
Can this mod be used on the cave dweller?
It's hard to tell what's supposed to be done with the PT2399 because the spec sheet sucks. But, I think this is where the info being discussed is coming from http://www.valvewizard.co.uk/smalltime.html (http://www.valvewizard.co.uk/smalltime.html) and specifically http://www.valvewizard.co.uk/PT2399_Data_Notes.pdf (http://www.valvewizard.co.uk/PT2399_Data_Notes.pdf).
And, it is definitely true that if you measure the resistance betweens pins 3 and 4 you get a very low resistance. On the one I just tried, it was about 30Ω.
In general, when there is a digital and an analog ground the point isn't that they are two different grounds and need to be run separately or anything like that. It's because to reduce noise, the two grounds need to come together at a point of a large conductive mass. This isn't possible to do in the chip, so they are brought out individually and connected on the PCB. I have no idea if that's the intention on the PT2399 though, because the spec sheet sucks (I'll probably say that again soon too).
It's interesting that the timing resistor is shown going to the digital ground. If the intention of the Agnd and Dgnd is what you normally see, that wouldn't matter much. on the other hand, it does seem weird that there is an internal connection between Agnd and Dgnd to begin with and maybe their intentions are completely different. But, we'd never know because the spec sheet sucks. ;D
So what you're saying is the spec sheet sucks? :o
Quote from: gordo on October 09, 2013, 01:35:44 AM
So what you're saying is the spec sheet sucks? :o
I wasn't sure I'd made that point strongly enough.
I'm still trying to figure out how connecting the delay resistor to ground via pin four through the 10Ω and thus through pin three is supposed to reduce noise compared to just hooking it to ground. (Assuming, that the diagram from Valve Wizard is the whole story.)
So...
Basically, we're saying 'we've been doing it all wrong' with the PT2399?
I dunno. I'm gonna have to breadboard this I think. I won't believe it till I can compare the 'normal' vs the 'updated'.
Jacob
My cave dweller will not make it to an enclosure if the digital artifacts/noise on repeated delays is not eliminated. I was going to post a sound clip but haven't had time.
How does the sea urchin/ deep blue prevent this kind of noise? We sell the mad professor pedal at work an I've never heard that kind of noise come through.
Jkokura.. Any news on that breadboarding?
Enviado de meu AT10-A usando Tapatalk 4
I've not be able to hear a difference in noise by connecting or disconnecting pin 3/4 or connecting the resistance off pin 6 to pin 4.
I think what it boils down to is that some chips are just really noisy, and most are somewhat noisy, and a very rare few are actually quiet.
My advice? Filter heavily, filter often. 8)
I've tried many things to limit noise in those chips.
C.J. has it right above, filter...filter....filter... or live with some noise ;)
Josh
How does the deep blue / sea urchin filter it out?
I haven't breadboarded it, but I still have heavy doubts. Seriously. We've all be playing with these chips for a long while now. But all of the sudden, someone comes up with some sort of solution that we haven't seen before?
Jacob
How can you filter out the noise but maintain fidelity?
Quote from: otsismi on October 12, 2013, 03:30:18 AM
How does the deep blue / sea urchin filter it out?
Aggressive passive low-pass filtering on the delay line.
Quote from: otsismi on October 12, 2013, 08:13:28 PM
How can you filter out the noise but maintain fidelity?
I don't think it's possible. Maybe with a compandor and a light amount of low-pass filtering, but it's a pain in the ass.
Quote from: culturejam on October 12, 2013, 11:42:36 PM
Quote from: otsismi on October 12, 2013, 03:30:18 AM
How does the deep blue / sea urchin filter it out?
Aggressive passive low-pass filtering on the delay line.
Active lowpass filters at the input and output of the PT2399 and additional passive lowpass at the output, like most designs based on the Rebote 2.5.
The Cave Dweller is different, the two opamps of the PT2399 are not used as filters, only passive filtering is applied.
Quote
Quote from: otsismi on October 12, 2013, 08:13:28 PM
How can you filter out the noise but maintain fidelity?
I don't think it's possible. Maybe with a compandor and a light amount of low-pass filtering, but it's a pain in the ass.
Right.
I built the cave dweller but can't box it up with all that noise. People have good results from the sea urchin?
Quote from: culturejam on October 12, 2013, 11:42:36 PM
[...]
Quote from: otsismi on October 12, 2013, 08:13:28 PM
How can you filter out the noise but maintain fidelity?
I don't think it's possible. Maybe with a compandor and a light amount of low-pass filtering, but it's a pain in the ass.
The Biyang "Analog" Delay uses an SA571. I can't say that it does anything for the fidelity of the audio. My guess is that it's only in there because it was in the BBD circuit that they lifted the design from. The pedal isn't bad, but there is nothing special about the quality of the audio. It's nowhere close to my DL-8 for example. It's comparable to all of the other PT2399 delays I've played with.
Quote from: RobA on October 13, 2013, 10:07:33 AM
The Biyang "Analog" Delay uses an SA571. I can't say that it does anything for the fidelity of the audio. My guess is that it's only in there because it was in the BBD circuit that they lifted the design from.
You can't make a 2399 have high fidelity. It's just not part of the design (the max bandwidth is crappy to start with). The best "hi fi" tone you'll ever get out of one is at about 250ms. Beyond that, you just have to accept it's going to be either noisy or heavily filtered.
Quote from: RobAIt's nowhere close to my DL-8 for example.
And it shouldn't be. That's a very apples-to-pineapples comparison. The DL-8 has a heavy duty DSP engine under the hood. It's like comparing the Millenium Falcon to a '72 VW Beetle. ;D
NE571-SA571 will help...
After sorting out bunch of PT's to get the cleaner one i was able to get rid of the inherent «pshhhht» after repeat with delay times around 400ms....after that it was coming back but less loud...
The core delay circuit i was using with the compander is the DeProfundis Delay that CJ designed and that is HIGHLY filtered....
I'll dig out that bunch of wire....and try that «revelation»...
Quote from: culturejam on October 14, 2013, 02:30:33 PM
[...]
Quote from: RobAIt's nowhere close to my DL-8 for example.
And it shouldn't be. That's a very apples-to-pineapples comparison. The DL-8 has a heavy duty DSP engine under the hood. It's like comparing the Millenium Falcon to a '72 VW Beetle. ;D
True except for the point that, since the Biyang delay I have was branded as an Akai pedal, the original list price of the Biyang was actually more than the Hardwire (not that I actually paid anywhere near that much for the Biyang).
It would be very interesting to know what is in the Hardwire pedals. I can't tell from mine because the chip is a custom branded SoC.
Yeah, the RV-7 I have says "AudioDNA - Harmon" on it. I know Harmon is the parent company of Digitech/DOD, so maybe it's something they actually developed. Who knows?
Quote from: culturejam on October 14, 2013, 08:17:49 PM
Yeah, the RV-7 I have says "AudioDNA - Harmon" on it. I know Harmon is the parent company of Digitech/DOD, so maybe it's something they actually developed. Who knows?
Isn't that Harman?
Yeah I think it is Harman.
They are a big company with lots of digital audio sub-companies, so I suppose that it is possible that it is something entirely their own design. But, I always figured that it's based on at least some other company's core FPGA, DSP, or MCU with someone else's AD/DA bolted on to it on the chip. Either way, it certainly does make for clean hardware design in all their digital pedals.
The main reason I was interested was that I've been hoping to find a DSP or MCU with an attached CODEC just to make the whole hardware side of doing digital DIY pedals simpler. I haven't been able to find anything yet. (Well, except for one from Cirrus-Logic, but I don't like the programming environment limitations.)
Quote from: RobA on October 15, 2013, 01:25:02 PM
The main reason I was interested was that I've been hoping to find a DSP or MCU with an attached CODEC just to make the whole hardware side of doing digital DIY pedals simpler.
Now that would be great!
Quote from: RobA on October 15, 2013, 01:25:02 PM
The main reason I was interested was that I've been hoping to find a DSP or MCU with an attached CODEC just to make the whole hardware side of doing digital DIY pedals simpler. I haven't been able to find anything yet. (Well, except for one from Cirrus-Logic, but I don't like the programming environment limitations.)
So the Spin FV-1 or Cool Audio V1000 don't meet the requirements? I'm very new to the digital side of things, so excuse my ignorance if that was a dumb question.
It depends on what you want to do. I'd say the Spin Semi FV-1 would be usable for some effects, but the things I want to replicate from my software based effects (AU's) need more computational power and RAM. I haven't looked much at the Cool Audio chip because I thought the programs were fixed and I think it still needs an external CODEC.
What would be ideal for many of the effects I want to do would be a Cortex-M4F with an integrated ADC/DAC.
On the good side of DIY digital effects, the Arduino Tre is going to be released in the beginning of 2014 and it's supposed to have both an Atmel MCU and an Arm Cortex-A8 with stereo audio I/O on the board. I'm not sure how big it's going to be yet or what the price is, but it's going to be usable for at least some audio applications.
Quote from: RobA on October 15, 2013, 03:08:45 PM
On the good side of DIY digital effects, the Arduino Tre is going to be released in the beginning of 2014 and it's supposed to have both an Atmel MCU and an Arm Cortex-A8 with stereo audio I/O on the board. I'm not sure how big it's going to be yet or what the price is, but it's going to be usable for at least some audio applications.
Yes, the Tre looks promising. Let's see if the audio system will be good enough for realtime. But could inspire great projects nonetheless. Guess it is >US$100.
Quote from: kothoma on October 15, 2013, 06:12:17 PM
[...]
Yes, the Tre looks promising. Let's see if the audio system will be good enough for realtime. But could inspire great projects nonetheless. Guess it is >US$100.
I'm guessing it's going to be more like US$50. Since it's basically a BeagleBone Black mixed in with an Uno I think they can do it for around there. I need to look into it more to see how the audio is set up. I think that's going to be where the big questions are. I'm hoping that they've got some I/O pins that give direct access to the CODEC.
Quote from: RobA on October 15, 2013, 08:55:17 PM
Quote from: kothoma on October 15, 2013, 06:12:17 PM
[...]
Yes, the Tre looks promising. Let's see if the audio system will be good enough for realtime. But could inspire great projects nonetheless. Guess it is >US$100.
I'm guessing it's going to be more like US$50. Since it's basically a BeagleBone Black mixed in with an Uno I think they can do it for around there. I need to look into it more to see how the audio is set up. I think that's going to be where the big questions are. I'm hoping that they've got some I/O pins that give direct access to the CODEC.
Can't find any details anywhere.
Nope, me either. And, the audio is different on the BeagleBone Black, so looking there isn't any help either. It looks like we'll have to wait for more details. The one thing I have figured out by looking at the photos is that the board is going to be bigger by quite a bit than the Due. That's unfortunate really.
Quote from: kothoma on October 15, 2013, 02:08:21 PM
Quote from: RobA on October 15, 2013, 01:25:02 PM
The main reason I was interested was that I've been hoping to find a DSP or MCU with an attached CODEC just to make the whole hardware side of doing digital DIY pedals simpler.
Now that would be great!
Well, looking more into the Raspberry Pi I stumbled upon this little I²S guy:
http://eu.mouser.com/Search/Refine.aspx?Keyword=wm8731
http://www.wolfsonmicro.com/products/audio_hubs/WM8731/
http://www.wolfsonmicro.com/documents/uploads/data_sheets/en/WM8731.pdf (Have a look at p60.)
http://www.mikroe.com/add-on-boards/audio-voice/audio-codec-proto/ (€15.20 at Mouser)
[Edit: forgot to mention: this one uses for input only the mono mic pin, the stereo line in pins are not used :(]
And indeed someone tested it sucessfully:
http://blog.koalo.de/2013/05/i2s-support-for-raspberry-pi.html
Just add a little buffer/booster to the circuit and plug in your guitar?
Thanks for the links to the projects. They could be very useful. I've got some of the WM8731 and some Cirrus Logic CS4270 as well on DIP adapter boards and they both work well for getting audio into MCU's, Raspberry Pis, etc. but that little breakout board looks like it could be really handy for experimenting with. If I can ever get my hands on a BeagleBone Black, I'll probably end up using either of these two CODEC's to test it with. The WM8731 is also used in this shield for the Arduino http://www.openmusiclabs.com/projects/codec-shield/ (http://www.openmusiclabs.com/projects/codec-shield/). They've got the schematic available for the complete shield as well.
I'd still like a complete single chip solution for smaller digital projects. I've been wondering more-and-more if the custom chip in the Digitech stuff is an FPGA and I'm thinking of going down that route. Of course, that's a whole new world of programming and interfacing I'll have to learn...
Quote from: RobA on December 08, 2013, 03:00:30 PM
... They've got the schematic available for the complete shield as well.
Right. Found it in their wiki. Thanks for this hint!
Quote
I'd still like a complete single chip solution for smaller digital projects.
Strange that there wouldn't be such a thing. Indeed it would be great to have and build a compact generic platform with.
For now I'll try my luck with the RasPi and a USB audio interface (which can drive you crazy).
I haven't tried using USB audio into the RasPi yet. In general though, I think using USB audio into various of the devices opens up a whole range of devices to use as processors. On the input and ADC side of things, Atmel and XMOS have some pretty slick chips to help with the USB audio connections and some processing and interface to pots and switches and such.
Quote from: RobA on December 08, 2013, 05:29:34 PM
[...] Atmel and XMOS have some pretty slick chips to help with the USB audio connections [...]
Providing a USB host (or client)?
Either side I think, but I've mainly looked at it for the client side. I've been thinking of doing a "pedal" that would let me connect to an iPad, Android (if they ever fix the audio/RT issues), BeagleBones, etc. for the digital processing and I've kinda settled on doing it as a USB audio device to get the universal connection.
Quote from: RobA on December 09, 2013, 03:07:58 PM
[...] Android (if they ever fix the audio/RT issues) [...]
I think I read some days ago that Samsung succeeded in adapting Jack(?) to Android. Sorry, can't find that link any more.
Quote from: kothoma on December 09, 2013, 09:18:00 PM
Quote from: RobA on December 09, 2013, 03:07:58 PM
[...] Android (if they ever fix the audio/RT issues) [...]
I think I read some days ago that Samsung succeeded in adapting Jack(?) to Android. Sorry, can't find that link any more.
Interesting. I couldn't find anything on the JACK site. I'll do some more searching and see what I can find. Though, I'm not sure it would help with the latency anyway since the issue seems to be in the kernel and the basic design of Android. Maybe 4.4 will help with its new model, but I'm really not holding out much hope. At this point, I'm really hoping that some of the other alternative tablet OSes will be usable for audio applications.
http://jack-audio.10948.n7.nabble.com/Jack-Devel-JACK2-for-Android-td17329.html
[http://global.samsungtomorrow.com/?p=29466]
http://developer.samsung.com/samsung-mobile-sdk#professional-audio
Haven't dug any deeper though.
Quote from: kothoma on December 10, 2013, 06:47:37 AM
http://jack-audio.10948.n7.nabble.com/Jack-Devel-JACK2-for-Android-td17329.html
http://global.samsungtomorrow.com/?p=29466
Haven't dug any deeper though.
Thanks for the links. It looks like the JACK implementation is very limited to just a couple of Samsung devices. And, even on those it looks like the source is modded so that even the MIDI implementation isn't low latency. I don't know for sure though. I did some web searching based on the info in the links though and the results still don't look good for KitKat at this point. I guess that might change in the future. I guess we'll have to wait to see some reports from users in the wild to know how well each of these work.
Meanwhile, I still can't get my hands on the new BeagleBone because they are sold out everywhere. Argh, they look so promising.
Quote from: RobA on December 10, 2013, 08:43:00 AM
[...] It looks like the JACK implementation is very limited to just a couple of Samsung devices. [...]
That's my impression too. I'm not sure about how much is open sourced here and what is proprietary.
But it's good to see that someone works on that ill-designed Android sound architecture.
On the other hand I never understood why anyone would need Android (in the form of a Java/Dalvik VM) on top of Linux in the first place.
Quote from: kothoma on December 10, 2013, 09:35:27 AM
Quote from: RobA on December 10, 2013, 08:43:00 AM
[...] It looks like the JACK implementation is very limited to just a couple of Samsung devices. [...]
That's my impression too. I'm not sure about how much is open sourced here and what is proprietary.
But it's good to see that someone works on that ill-designed Android sound architecture.
On the other hand I never understood why anyone would need Android (in the form of a Java/Dalvik VM) on top of Linux in the first place.
From what I saw on one of the blogs, Samsung have put the source in their open source repository and people have pulled it. But, it does sound like it depends on specific hardware details. That makes sense though since my impression is that the audio latency problems are due to a combination of hardware and software.
I agree completely about the Android on top of Linux thing. It'll be great once the truly open Linux based devices gain some traction. We really can't be too far off from a Raspberry Pi tablet.
Quote from: RobA on December 10, 2013, 10:39:45 AM
[...] it does sound like it depends on specific hardware details. That makes sense though since my impression is that the audio latency problems are due to a combination of hardware and software. [...]
Yeah, that may very well be.
Quote from: RobA on December 10, 2013, 08:43:00 AM
[...] the new BeagleBone [...]
BeagleBone Black?
http://www.ebay.de/itm/321268837618
Yeah, that looks like it. I'm not sure what the price point is supposed to be in the EU with VAT and all. The US list is 45 I think. Sparkfun is nearby to me and is supposed to have them back in in about a week. That gives me a little bit of time still before I have to make up my mind if I want to go that way or try FPGA's first.
Maybe I've been looking at in the wrong places, but I don't find any reports on realtime audio with a BeagleBone.
I've spent the whole weekend on setting up the RasPi for realtime audio. I'm near but not really there yet.
There are some projects on the beagleboard.org site that do audio applications. How you go about doing it is going to depend on which OS you use. But the CPU certainly has the power and support to do it. It has various RT support peripherals and I2C, I2S, and SPI built in. There are even some small RTOSes that are available for it. So, I'm sure that it will take some work to get it set up for audio applications, but I'm confident that it can handle it.
I'm interested in hearing how what you are doing with the Raspberry Pi works. I've got one already, but it's actually dedicated to running my electronics software, but least they are easy to get hold of now.
What initially appealed to me was the low power consumption of the Pi, which is ideal for running 365/24 servers (VPN, NAS, private cloud, mail server, DLNA/UPnP, you get the idea). Maybe I even get into some home automation sometime?
Only recently I considered using it for RT audio. So I started trying all my USB audio interfaces. And had an instant déjà vu. Not too much has improved here since my endeavors with UbuntuStudio five or six years ago. Plug and play? Dream on.
In addition there seems to be a serious problem with how USB 2.0 is implemented on the Pi, especially the USB 1.1 compatibility.
You either clock down to USB 1.1 or you have luck and get a USB 2.0 audio device working.
And as LAN is done via USB you better unplug here altogether once everything is set up.
On the software side you need to find out what of the OS to deactivate to get the most out of the CPU. Seems like one has to get rid of everything that has to do with the network to minimize hickups. For a start I would be glad to have a reliable software wire (copying input to output, no actual DSP). Next step would be delay and sampler/looper. But I almost got Guitarix working already. Convolution could be within reach. Now that would be something.
Haven't tried overclocking yet. Or building a cluster and going parallel (over GPIOs as LAN seems to be off-limits).
Edit: you really got me interested in the BeagleBone. Faster. More I/O pins, even analog ones. Nice.
I know next to nothing about FPGAs. No idea where to start and what would be needed.
So would it (in the long run) be possible to (more or less automatically) translate a csound or pd/Max script directly into a piece of hardware? (Just dreaming?)
I've got my Pi overclocked to a mid level. It helps a bit, but since each board can handle different levels, I don't think it's something that you can depend on to get algorithms running.
One of the appeals of the BeagleBone is that it's aimed at being kind of a super Arduino -- more project oriented. So, it's got more OS choices and a system of being able to configure the level of services in the OS that is relatively easy to work with. I've played a bit with the earlier BeagleBone and it is pretty easy. Now, there are things like FreeRTOS available and it gets even more interesting in that regard.
I'm really in the same situation with FPGA's. I've really only read about them. The initial appeal was being able to build my own SoC of a sorts with doing the AD/DA on the pins of the FPGA itself. So, simplifying the system. But, since the powerful FPGA's tend to have massive pin counts to begin with, I'm not sure that this is a better solution than just adding a good CODEC to the project. The bigger issue is the programming model is not as widely known and seems to me to be less well supported by open source programming tools. That's something that's important to me for the projects I have in mind.
That last point is probably relevant to your last question. I think it would be much easier to approach doing something like pD or Max on a Pi or BeagleBone than an FPGA based system. And that points to them more appropriate for the type of things I want to be able to do too. They also cost a lot less and that's important in this space too.