I'm pretty sure dac_write is nonblocking. If memory serves me correctly, it
returns -1 if there's not enough free space in the fifo, 0 otherwise.

On Fri, Sep 18, 2015 at 6:57 PM, Stuart Longland <[email protected]
> wrote:

> On 19/09/15 07:56, David Rowe wrote:
> > Thank you Stuart - I think that's the first patch for the SM1000!  Well
> > done.
> >
> > I'm camping this weekend at Mt Remarkable but will take a look at the
> > patches early next week and figure out where they fit in.
>
> No problems there.  I've been tinkering around with that for a bit now.
>  One thing I do notice is that timing seems to be off, I'm not sure why.
>
> Perhaps I'm overrunning a buffer somewhere?  Still getting to grips with
> how the DAC code works.  I hacked up a version of the DAC unit test with
> this:
>
> int main(void) {
>
>     struct tone_gen_t tone_gen;
>
>     dac_open(4*DAC_BUF_SZ);
>
>     while(1) {
>         tone_reset(&tone_gen, 500, 400);
>         while (tone_gen.remain) {
>             int16_t buffer[800];
>             int count;
>             for (count = 0; (count < 800) && tone_gen.remain; count++)
>                 buffer[count] = tone_next(&tone_gen);
>             dac1_write(buffer, count);
>             dac2_write(buffer, count);
>         }
>
>         tone_reset(&tone_gen, 1000, 100);
>         while (tone_gen.remain) {
>             int16_t buffer[800];
>             int count;
>             for (count = 0; (count < 800) && tone_gen.remain; count++)
>                 buffer[count] = tone_next(&tone_gen);
>             dac1_write(buffer, count);
>             dac2_write(buffer, count);
>         }
>     }
> }
>
> That should be, a 1kHz tone every 500 msec with a 500Hz tone the rest of
> the time.
>
> --------##--------##--------##--------## …
>
> Instead I get a burst of stuttery 1kHz beeps in amongst a drone of 500Hz.
>
> -----#-#-#-#-------#-#-#-#-------#-#-#-#----- …
>
> Not sure what's going on there.  It might need to wait until I pick up a
> suitable STM32F4-based board that I can hook my JTAG to.
>
> If I write a quick C program on my host that `fwrite`s the samples to
> stdout, and pipe that to `aplay`, it works fine.
>
> I also have a morse code generator (attached) that can take an arbitrary
> string and play it as morse at any speed and frequency.  Speed is set by
> the "dit" time.  I figure the user can set a preferred speed in WPM that
> we translate to "dit milliseconds" using some standard like the PARIS
> standard.  The word "PARIS" is 50 dits long → Wikipedia reckons that
> equates to T=1200/W where T is in milliseconds and W is words per minute.
>
> An example program:
>
> #include <stdio.h>
> #include "morse.h"
>
> int main(void) {
>         struct morse_player_t mp;
>         mp.freq = 800;
>         mp.dit_time = 100;
>         morse_play(&mp, "TESTING 1 2 3 4");
>         while(mp.msg) {
>                 int16_t sample = morse_next(&mp);
>                 fwrite(&sample, sizeof(sample), 1, stdout);
>         }
>         return(0);
> }
>
> This command plays nice clean morse on my host with the above code:
>
> gcc -I src -o test test.c src/tone.c src/sfx.c src/morse.c \
>         && ./test | aplay -c 1 -f S16_LE -r 16000 -
>
> So the building blocks for a menu system are there.  More work is needed
> on the playback side of things (as discussed) and of course, detecting
> long vs short presses of buttons, but things are moving somewhat.
>
> A module that handles playback of pre-recorded Codec2 samples would be a
> next step after getting some basic menu logic together, that would allow
> for voice prompts (rather than morse).
>
> I'll look at that after I get something basic going.
>
> > If you, or anyone else reading, is interested, it would be great to have
> > some help porting the cohpsk modem to the SM1000.  A first step would be
> > to look at the memory usage, like I did for the fdmdv modem:
> >
> >    http://www.rowetel.com/blog/?p=3427
>
> Can't promise anything there, but I can have a look.
>
> Regards,
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to