Show Posts
Pages: [1] 2 3 ... 42
1  Products / Arduino Due / Re: TLC5940 change frequency to 20kHz on: September 15, 2014, 11:25:26 am
I believe the TLC5940 PWM is always 1/4096th of the GSCLK input, and the maximum GSCLK speed is approx 31 MHz.

No amount of wishing a thing to be more than it actually is can make it so.
2  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:22:47 am
Well, I think I need to stop following this thread now.  It's wasted enough of my time.

If you have written a better message, with code and details, I probably would have helped.  Maybe someone else will do so, if you write a good question with details.  But I'm done.  You've used up all the time and attention I'm willing to give.
3  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:16:58 am
Do you believe people on this forum have extrasensory powers like clairvoyance, to see the mistakes you've made without you having to provide any information about what you've done?
4  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:15:24 am
I have no idea either.
5  Products / Arduino Due / Re: Audio (yes, I know) on: September 15, 2014, 03:11:02 am
You're probably doing something incorrectly.
6  Products / Arduino Due / Re: Best book for Due hardware information? on: September 11, 2014, 05:39:44 am
The board clearly wasn't designed as a DAC to take your CDs and produce audiophile grade analog output (if so, it would be a steal at 10x the price if it could deliver on that promise).

Have you seen the audio library and hardware I've been developing on Teensy?
7  Products / Arduino Due / Re: Audio (yes, I know) on: September 10, 2014, 03:23:45 pm
I'm trying to build a one way ethernet radio, but I can't get the code to work at all...

For the last year, I've been working on an audio library for Teensy 3.1.  It has a lot of features, but recording and streaming still need a lot of work.  It's not so easy.

I've been helping many of the early users of my library.  When they communicate effectively, usually that process leads to me improving the library, and they get great working projects.  But communication is the key, and sadly, it's really lacking in this thread.  I just don't think I can do much more to help you, staurtm34, even if you were using the Teensy hardware.  On Due, there's far less in the way of well maintained libraries.

8  Products / Arduino Due / Re: Audio (yes, I know) on: September 09, 2014, 05:59:36 pm
What software can receive the packets and play them?
9  Products / Arduino Due / Re: Audio (yes, I know) on: September 07, 2014, 03:51:39 pm
I'm curious what you're trying to do here?  I a moment, I'll point out a few problems with the latest code, which should help you.

In return, I hope you'll be willing to spend a few moments explaining this application.  I really do want to know.  For the last several months I've been developing an audio library for Teensy.  Recording is one of the areas where I've done very little work, so even if you had the right hardware, my library as-is probably won't help.  Really, I'm hoping you'll help me, not with specific code, but with some explanation of what you're trying to really accomplish (eg, if all this code could somehow magically work).  By better understanding the application, maybe I can plan future audio library development?

Anyway, back to this code.  I see 5 possible issues....

First, it looks like you might have a buffer overflow.  Two loops use "while (inccnt<8001) {", with an increment at the end.  The first iteration of the loop will have inccnt equal to zero, which accesses the first location in the array, since arrays are zero-based.  The last iteration will have inccnt = 8000, which accesses 1 beyond the end, since it is only 8000 long and zero-based.  The last location is accessed when inccnt = 7999.

Second, your UDP send code use Udp.print(), which is probably not what you want.  For unsigned numbers, it will print ascii characters.  You almost certain should use Udp.write(), to copy the data directly to the UDP packet without turning it into printable ascii characters.

Third, your code appears to use "inccntr" in the second loop without first setting it back to zero.  The condition "while (inccntr<8001)" will NEVER occur, because the variable was left greater than 8001 from the previous loop which collected the audio samples.  As a result, your code will only call the Udp.beginPacket() and Udp.endPacket() functions, transmitting an empty packet.  The audio data will never leave the Arduino.

Fourth, UDP packets have a maximum length.  There are several different limits, all of them well under 8000 bytes, so you can't possibly send all the bytes as a single packet.

http://stackoverflow.com/questions/1098897/what-is-the-largest-safe-udp-packet-size-on-the-internet

Based on that info, 500 looks like a good number to use.  You'll need 16 packets to send all 8000 bytes.

A fifth possible issue, which isn't technically a bug in your code, but rather a limitation in the Arduino Ethernet library, it terrible inefficiency for sending 1 byte at a time.  You should really use Udp.write(buffer, 500) to send 500 bytes all with a single write.  Perhaps something like this:

Code:
      inccntr = 0;
      while (inccntr<8000) {
        Udp.beginPacket(broad, remPort);
        Udp.write(audBuffer + inccntr, 500);
        Udp.endPacket();
        inccntr = inccntr + 500;
      }

There, I've identified 5 issues with this code which are probably preventing you from getting any results.  There may be more problems, but those are the 5 I can see from just reading your code quickly (eg, not actually running it here on an Arduino Due board with Ethernet Shield and microphone circuit).  Hopefully this will help you.

I really would appreciate if you would return this favor by taking a few moments to explain what your project is really about.  What are you trying to ultimately accomplish?  This information isn't for the purpose of debugging your code.  I'm asking you to take a moment to help me, so I can understand your application.

I am working on an audio library (for Teensy 3.1, not targeting Arduino Due).  Eventually, I want to add awesome recording capability to my library, so these types of projects will be very easy.  But first, I want to understand your project, so I can use that understanding as I work on my library.  I've made a significant effort to help you, and I hope you will be willing to return the favor by explaining your application.


10  Products / Arduino Due / Re: DmxSimple on: September 07, 2014, 03:03:54 pm
I have already an Arduino Uno, I can send DMX, now I will see to receive DMX. Is there another library?

On that page for the Teensy port for DmxSerial is a link to this forum thread, where Ward wrote DMX receive code.  Again, it's only for Teensy 3.X, but maybe you can use it to at least get started?  At the very least, it shows DMX receive is possible on ARM.
11  Products / Arduino Due / Re: DmxSimple on: September 07, 2014, 02:57:58 pm
DmxSimple doesn't work for the Due and it's possibly too much work to port it to the ARM hardware platform.

I ported DmxSimple to Teensy 3.1, so it certainly can be ported to ARM with some work.

http://www.pjrc.com/teensy/td_libs_DmxSimple.html

Maybe my version will give someone a head start for porting to Due?
12  Products / Arduino Due / Re: Please point me at instructions for speeding up the Due beta compiler. on: August 24, 2014, 04:24:29 pm
You don't mean that?

Yes, you're right, I oversimplified in that quick comment.

Quote
  Files need recompiling when any file they depend on changes, or
the board selected changes, etc etc.

Yes, of course it does that, using the .d dependency files created by previous runs of the compiler.

I've published this patch for several years in Teensyduino and Arduino has published in since version 1.0.1.  It's worked very well all this time.

All the source is available, if you're concerned about the implementation.
13  Products / Arduino Due / Re: Please point me at instructions for speeding up the Due beta compiler. on: August 24, 2014, 04:47:49 am
Sadly, it seems the patch I contributed to Arduino years ago, to only recompile files that have actually changed, has somehow been lost in 1.5.7.  This has recently been reported as a bug, so hopefully it'll get fixed in 1.5.8 or 1.5.9?

https://github.com/arduino/Arduino/issues/2255

The known bug where a space isn't recognized in the pathname is my fault.  I mostly use Linux, and then I port to Mac, and I always do Windows last, because it's the most painful.  When I tested on Windows, I used "c:\arduino", mostly because that makes things simpler to copy files over from my Linux machine, so I didn't notice the bug with not properly handling spaces.

I fixed this some time ago in Teensyduino, but sadly my code has drifted pretty far from Arduino's version, and they're in deep maintainence mode on the 1.0.x branch now, so odds are slim my fix will ever get into the 1.0.x branch.  It's also a good question whether they'll ever release 1.0.6....

Due's slow upload speed is mostly caused by bugs in Atmel's bootloader.  The bootloader is permanently burned into the mask rom inside the chip, so it can be updated.  Atmel is unlikely to ever fix those bugs, due to the high cost of revising the silicon.  Their own FLIP programmer apparently uses the buggy bootloader to upload a faster one to RAM, which it then runs and uses to upload code quickly.  Of course, Atmel never published any of that code, so Arduino can't use it.  It seems unlikely anyone will ever go to the trouble of developing something like that for Arduino Due.

Edit: I have put a *lot* of work into optimizing upload speed on Teensy 3.1.  If you'd like to see how fast upload can be, give it a try.  I believe on most computers, where there's significant USB bandwidth available (eg, not all used up by webcams or USB hard drives), it's limited in speed only by the USB enumeration time to detect the reboot, and the actual flash write throughput on the chip.
14  Products / Arduino Due / Re: Arduino Due Audio Library and Performing Other Tasks During Playback on: August 12, 2014, 01:23:37 pm
I'm curious to hear how using those timers work out.  I hope you'll post updates here, whether it works or does not work out.

Because this forum is for Arduino products, I'm reluctant to talk more about other hardware.  If you'd like to chat about the other library, there's a link on that github page to another forum.
15  Products / Arduino Due / Re: Arduino Due Audio Library and Performing Other Tasks During Playback on: August 12, 2014, 07:03:53 am
This might be a bit off topic, but you may be interested in an alternate audio library I've been writing for Teensy.  It's still at a fairly early stage of development.  A major feature (which does work well) is playback in the background.  In fact, this new library lets you create many audio objects, interconnected in arbitrary ways, with automatic audio data flow between them, all updated in the background.  For example, you can create 3 wav file players, connect them to the inputs of a 4 channel mixer, and then connect the mixer to the DAC output, or an audio shield output, or both.

Unfortunately, this new library requires different hardware.  While the audio processing objects are relatively pure software, all the input & output objects are coded for the DMA hardware on Freescale's chip.  The library also makes heavy use of the Cortex-M4 special DSP accelerating instructions, which dramatically speed up some objects like the FFT, BiQuad filters, and waveform synthesis.

https://github.com/PaulStoffregen/Audio
Pages: [1] 2 3 ... 42