What is the experience running programs written in an audio synthesis/analysis language such as ChucK, Pure Data, Csound, Supercollider, etc. in an embedded device such as an Arduino Mega, Beagle Board or a custom board with a microprocessor or DSP chip?
I would like to know which language and hardware you chose and why. What were the obstacles, etc.? My objective is to run programs that can be easily programmed by musicians/producers in a board that is not too expensive.
I received input from someone who is successfully running ChucK programs in a Beagle Board (Ubuntu Linux on a Beagle Board running ChucK), but his choice of language and hardware was made very lightly, his setup is not using the DSP in the Beagle Board and it seems like overkill to run a whole Linux install to process audio signals.
Any input is appreciated!
Update: I found Zengarden which is a Pd runtime implementation (as a standalone C++ library) and runs well on ARM based devices. For now, I'll go with the BeagleBoard and Zengarden but in a later stage of the project, I'll need to replace the BeagleBoard with something that costs less.
I'd love to hear more input from the community.
Thanks everyone for your comments and answers. For everybody else's reference, I ended up writing a JACK client in C++ that parses and interprets PureData patches and ran it on a BeagleBoard with Angstrom Linux and JACK server. Here's a video and a tutorial that I wrote: http://elsoftwarehamuerto.org/articulos/691/puredata-beagleboard/
First, I am not an audio programmer, so I'm not familiar with the actual demands of the signal processing necessary to achieve what you want to achieve.
But, it's difficult to contrast something like the Beagle Board and the Arduino Mega, since they're really in different leagues of base performance. The Beagle Board is a 1 GHz ARM vs the Arduino Mega's 16 MHz. That tells me that whatever processing you may be interested in doing may well be within the capabilities of the Beagle Board, but the Arduino Mega would have almost no chance without an attached DSP to do the actual work.
The next consideration, is whether any of the packages you were considering using actually target DSPs for their runtimes. At a glance they seem like high level sound processing languages. With the Beagle Board, you may well have the processing power to evaluate and compile the sound source code that these packages use and let them compile in to their targets, but on the Arduino Mega, that seems unlikely.
If all you're doing is working with a piece of hardware that will be running the artifacts created by the packages you mentioned, then the Arduino Mega may well be suitable as the "development" is done on a more powerful machine. But if you want to work with these packages as is, and use them as a development tool, then running them on a Linux port to something like the may simply be a better option.
Again, after casual looking about, the Arduino Mega is roughly half the price of the Beagle Board, but the Beagle Board may well let you work at a much higher level (generic Linux). Whether either will be powerful enough for your final vision, I can't say. But I would imagine you could get a lot farther, a lot faster, using the more powerful system -- at least in the short term.
Related
I need to do some NON-STANDARD signal processing operations with an RFID-reader, so I'd like to know if it is possible to extract antenna's individual analog (actually digital samples right after ADC) input signal samples with Motorola FX7500 (if you know how this works on FX7400 or FX9500, please do tell, could be helpful). Samples would be processed in a JAVA-based host computer program.
What I've already tried:
Investigating Motorola's own RFID3 API's possibilities, it doesn't go deep enough to actually get in touch with input analog signal samples.
Using LLRP to its full extent, it doesn't allow analog signal sample access either. RFsurvey-functionality would have been helpful to some extent, but FX7500 doesn't support it either.
Accessing RFID-reader's linux terminal, trying to find the driver function(s), that could listen the input sample stream. If current input sample(s) could be extracted from the input stream, I could (in theory) make a script, that would save a few of those sample values in a txt-file in the host computer during a tag inventory round. My linux skills are kinda bad, hence I ask this question.
The only realistic way to solution seems to be via linux terminal, so if you folks have any ideas about that (where to look and what to do), please advise!
Contents of reader:
rfidadm#FX7500abcdef:/$ ls -1
apps
bin
dev
etc
home
include
lib
linuxrc
media
mnt
platform
proc
readerconfig
run
sbin
sys
tmp
usr
var
I cannot completely rule that out, but it's highly unlikely you can get the raw signal digitized; the devices you're looking at aren't really software defined radio devices, typically.
"speaking" RFID physically is a bit different from "usual" wireless communication: The reader doesn't only observe the energy transmitted from the tag, but more importantly the fluctuations of energy extracted from the near field of the reader's antenna coil. Hence, you don't actually have a baseband of RF bandpass signal, but hardware-specific modulations of transmitted (and inversely, antenna-reflected) energy. Demodulation is hence usually done in specialized hardware.
However, do not fret: It's totally possible to build a software defined RFID reader. There have been several approaches to that, but personally, I trust these based on Ettus USRPs and/or GNU Radio best. Look through the results IEEExplore gives you, eg. this search.
Most probably this is not possible with the Motorola readers. What you can do, is use one of the RFID chipsets available on the market: either the AMS RFID IC's, or the Impinj RFID IC's. As far as I know, both IC's support retrieving the digital samples that are received. They also have a development kit to test-drive the IC's.
How can I play and synthesize custom waves in Lazarus/Free Pascal? The solution has to be realtime-friendly, as it is for a game engine. It should be also multi-platform, so it can be used on win32, Linux and Mac. FMOD/BASS are out (even if aplicable) as I don't want to pay fees if I will want to use it commercially.
There are solutions to that. My favourite library is Steinberg's ASIO. It is a very simple API, it's got wrappers for Linux, Windows, MAC and i guess some other platforms as well. It is a professional API for low-latency recording / playback. You usually need a soundcard that supports it, but recently some drivers emerged, using native platform API to emulate ASIO device (e.g. ASIO4ALL in windows).
ASIO's got a simple function in which buffers are swapped, where you can generate your wavefrom procedurally to be played back practically immediately (there are latencies in order of milliseconds). That's for the realtimeness.
The API as such is royalty free which means you can use it in a commercial project and don't have to pay anyone.
As for Pascal bindings, I believe you will have to do that yourself. But the whole initialization and operation of ASIO is <100 lines of C/C++ code (and you actually only need to control sound synthesis and maybe device selection - ony two functions that need to be exported by the wrapper) so that really should not be hard at all.
On a basic embedded systems speaker with a single line of output, wiggling the output as 0 or 1 in a for given periods produces sound.
I'd like to do something similar on a modern Linux desktop. A brief look-see of Portaudio, OpenAL, and ALSA suggests to me that most people do things at a considerable higher level. That's ok, but not what I'm looking for.
(I've never worked with sounds on Linux before, so if a tutorial exists, I'd love to see it).
Actually, it... kinda is. While you can generate the waveform yourself, you still need to use an API to queue it and send it to the audio hardware; there no longer even exists a sane way to twiddle the audio line directly. Plus you get cross-platform compatibility for free.
[...] embedded systems speaker with a single line of output, wiggling the output as 0 or 1 in a for given periods produces sound.
Sounds a lot like the old PC speaker. You might still find code for it in the Linux kernel.
I'd like to do something similar on a modern Linux desktop.
Then you need AFAIK a driver for ALSA. There you can find infos on how to write an ALSA driver. Use PWM to produce the sound.
Since there are many different sound cards and audio interfaces produced by different companies, there is no uniform way to have a low level access to them. With most sound I/O APIs what you need to do is to generate the PCM data and send that to the driver. That's pretty much the lowest level you can go.
But PCM data is very similar to the 0-1 approach you describe. It's just that you have the in-between options too. 0-1 is 1-bit audio. 8-, 16-, 24-bit audio is what you'll find on a modern sound card. There are also 32- and 64-bit float formats. But they're still similar.
Im doing a dsp project and i want to take an anolog file and convert it to a digital output using a microconroller attached to a ADC on a dsp board. How would i program this in c?
Pretty much its as simple as that, atleast i think.
This is what i need.
Input --------- Output
Angolog --> Digital
Digital --> Anolog
You really need to clarify your question. Like what do you mean by analog file? File systems are binary from a programming perspective, sure the media is magnetic or other technologies and there is analog involved. An ADC goes from Analog to Digital, so it is an an analog input not a digital output.
ADC analog to digital converter, takes analog inputs to the device and converts them to digital so you can use them inside the chip, program, save to files, etc.
DAC digital to analog converter, takes digital values and converts them to analog outputs.
In both cases you need to look at the specific details for the chips and the board. From a programming perspective if nothing else you need to look into the details for the ADC and or DAC. Microcontrollers having an ADC is not uncommon, but you need to read up on how to get the ADC on that microcontroller to initiate a sample, how to know when the sample has completed and how to read the digital data once the sample has been taken. DACs are often external, sometimes serial, so you may have to bit bang spi or i2c or look into what hardware the microcontroller might have for speaking spi or i2c or if there is a dac in the microcontroller, how to use it (what registers to write, etc).
If you have a specific publicly available microcontroller board, for example an eval board, then that makes it much easier for folks here or elsewhere to show you where to look for the schematics, data sheets, etc. Otherwise, even knowing exactly which microcontroller and what I/O pins are used, would be helpful when asking such a question. There are probably lots of example programs out there that could be borrowed from. And it could be as simple as a few lines of C to an existing library, or as complicated as many lines of C with interrupt service routines, and possibly some assembler.
This is extremely dependent on your hardware and there's no information in the question that would enable a real answer.
In general, you should see the documentation for your system, especially the AD/DA parts. There should be good examples. If there's a particular problem, post a more specific question.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I want to start FPGA programming. I don't have any knowledge at all about how FPGAs work and such. I would like to get a development board, not too expensive, but it should have at least 40 I/O pins. Anything up to $300 is OK.
I decided that I want to program in Verilog. I am not sure about the following:
How will my compiled 'program' be stored on the chip? I would guess the chip has some kind of EEPROM to save my program, but from what I have read, it is apparently stored in RAM. I want my program to remain on the chip (or to be loaded somehow) every time it powers up.
Can I buy a separate FPGA chip (not a whole development board) for production? And if yes, how can I upload my program to the separate chip? Does it in some way connect to the development board?
I'd recommend the Digilent Basys board as an introduction. It only has 16 external I/O, but it already has RAM, USB, switches, buttons, LEDs, 7-segment displays, a VGA connector, and a PS/2 connector onboard - You're unlikely to find an FPGA with fewer than 40 I/O pins. If you want I/O for another project, use the Nexys instead - More peripherals than I care to list, and also has a high-speed Hirose 43-pin connector if you have a project which specifically needs about 40 connections.
Also, consider how you want to interface with your PC. Is your goal to make an embedded system, or to interface with a computer through a PCI/Ethernet/USB connection?
Yes, you can buy separate FPGA boards for production - There's a dizzying array of options, though - Digikey has 5,300 at this time. You do need some way to program the FPGA, and an onboard NVM chip that programs the FPGA on startup is a popular option. However, you should start with a development board that's well supported and already has a programmer, toolchain and simulator available before you get too far into designing your board or worrying about how to save your program onto the chip. Those are good things to know, but they're not what you want to worry about right now. Good luck!
The whole point of using an FPGA is that your "program" is actually a circuit, not RAM. There are physical logic components that are configured when you write the bitstream to the FPGA. This is why they can run so much faster for specialized applications--you are basically making custom hardware.
Xilinx is one of the main FPGA manufacturers. Try their website. Check out the Boards & Kits section.
Try reading more about the technology before you get ahead of yourself. You will need a strong understanding of how FPGAs work before you can program them effectively. Wikipedia is a great place to start.
In Xilinx FPGA terminology the "program" is called bitstream. There are some FPGAs that have embedded flash to store the bitstream (e.g. Spartan 3AN). Most of the FPGAs require some external bitstream storage. Here is a configuration guide on how to configure an FPGA.
Yes you can. There are multiple ways to do configuration. Most of them require some external circuitry.
Check out Actels's new Smart Fusion FPGA. Its has a FPGA fabric of course, with a hard ARM MCU with a good analog end (DAC, ADC etc).
The Eval board is only 100$
http://www.actel.com/products/hardware/devkits_boards/smartfusion_eval.aspx
And all the software you need to get up and running if free.