Roman's btc 1 bit sound

Discussion in 'Embedded Systems and Microcontrollers' started by powzoom, Jul 20, 2009.

  1. powzoom

    Thread Starter Active Member

    Jan 18, 2009
    I've been trying to get Roman's Btc 1 bit sound encoding to work with a pic but all I hear is noise. Below is my code and attached is the output of pin RA5. Please let me know if there is anything wrong. The sound sample is at 8KHz and the pic is running at 8Mhz/4=2Mhz a cycle.

    const char sound_data[] =

    #define testbit_on(data,bitno) ((data>>bitno)&0x01)

    OPTION = 0b11001000; // bit 4 set means no prescale
    T0IE = 1; //enable TMR0 overflow interrupts
    ei(); // enable global interupts

    char c_bit =7;
    int i =0;
    char byte = 0;

    for (;;)

    count = 0;
    if (c_bit<=0)
    if (byte = sound_data)
    RA5 = testbit_on(byte,c_bit);


    void interrupt Timer0_ISR(void)
    T0IF=0; //clear TMR0 flag
  2. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    Gee thats hard to read without formatting. Try using the code tags nextime you post code please! :)

    I cant see any obvious bugs but it's a little convoluted. You could try getting rid of the funky looking macro and maybe use something a little easier to read (and debug) like this simple 8bit loop;

    Code ( (Unknown Language)):
    2. byte = sound_data[i];
    3. c_bit = 8;
    4. while(c_bit)
    5. {
    6.     while(!f_play); // wait for f_play to be set
    7.     f_play = 0;
    8.     if(byte & 0x80) RA5 = 1;
    9.     else            RA5 = 0;
    10.     byte = (byte << 1);
    11.     c_bit--;
    12. }
    13. i++; (etc)
    14. [/i]

    But that doesn't mean there isn't a bug elsewhere in your code etc. What program generated the BTc sound data you have in sound_data[] ?? Is it formatted to play MSB first? 8kHz is very low too, even if that is playing properly it will sound pretty trashy, you might want to bump up to 15625 or 19531 etc.
  3. hgmjr

    Retired Moderator

    Jan 28, 2005

    formatted up your code for easier viewing.

  4. powzoom

    Thread Starter Active Member

    Jan 18, 2009
    Sorry about the format, didn't realize about code tags. 8kHz is slow, yea, but I'm waiting for a 20Mhz oscillator to come in the mail. For now I have just the 8Mhz internal oscillator. With the 20Mhz I could use timer0 -> 1/(20Mhz/4) *256 -> tmr0 clicks every 51us or the same as 19531Hz.

    The program to convert is btc2ccs which I found on this post,
    It outputs the same numbers as the btc mikro .c format but formatted for copy and paste.

    I'm pretty sure its MSB first although I tried it both ways to make sure and I get noise each time. The sound clip is just a few seconds of voice.

    I've modified your code so that the chip isn't wasting cycles and can attend to other things eventually. However, the sound is still garbled and just noise.
    Code ( (Unknown Language)):
    1.     char c_bit = 0;
    2.     int i =0;
    3.     char byte = 0;
    5.     byte = sound_data[0];
    7.     for (;;)
    8.     {        
    9.         if(f_Play)
    10.         {            
    11.             if (c_bit==8)
    12.             {
    13.                 c_bit=0;
    14.                 i++;
    15.                 byte = sound_data[i];
    16.             }
    18.             if (byte & 0x80)
    19.                 RA5=1;
    20.             else
    21.                 RA5=0;    
    23.             byte = (byte << 1);
    24.             f_Play=0;
    25.             c_bit++;        
    26.         }
    27.     }[/i]
  5. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    Hmm, I hadn't seen that BTC2CCS.exe converter before. Thanks for the link.

    Since that program converts sound from MikroC format as produced by my BTc sound encoder software, I assume you used that to generate the original BTc sound data?? How did the sound look? Was it good in amplitude, ie most of the sound swinging from top to bottom on the BTc encoder screen? 1 bit sound is critical regarding amplitude as the PCM noise is fixed amplitude and large, so you need the largest possible amplitude sound wave. That's covered in the help file that comes with the BTc encoder.

    Other than that, one possible reason might be that the program you used to convert to CCS format might have swapped the MSB first of the BTc format to LSB first. Thats DOES garble the sound pretty bad. You could try changing your code
    Code ( (Unknown Language)):
    2.             if (byte & 0x80)
    3.                 RA5=1;
    4.             else
    5.                 RA5=0;    
    6.             byte = (byte << 1);
    7. to:
    8.             if (byte & 0x01)
    9.                 RA5=1;
    10.             else
    11.                 RA5=0;    
    12.             byte = (byte >> 1);
    Which is a pretty easy test.

    Finally, 8kHz is never going to sound good, even with a high amplitude original sound and good encoding parameters. There will be a lot of loud noise at bitrate/2 /3 and /4, which is 4kHz, 2.6kHz and 2kHz. Right in the powerband of most speakers and the human ear. You really should change to 19531 if you can and use some pretty good low pass filtering, generally consider the RC of the BTc filter as a "modeling stage" to reproduce the basic waveform and add additonal RC filter stages to try to remove most of the PCM noise. At 8kHz it is just not gonna sound that good. :)
  6. powzoom

    Thread Starter Active Member

    Jan 18, 2009
    Thanks for the replies. I took some time off from the project and came back today. I figured out the problem and it was something really stupid. I forgot to but 0b before a binary number that sets the oscillator speed. Funny how something so small causes the whole thing not to work right. Also funny how I figured out the problem in minutes as opposed to the hours I stared at it the other day, ha. I've also added an active filter to take out the higher frequencies. It sounds cheapish but there's no problem in hearing the voice in the recording. I'm still waiting on the 20Mhz oscillator to up the sample rate.
  7. mauro.laurenti

    Active Member

    May 8, 2009

    I do not know the frequencies you are working on, but since you have an op amp, why not make a 2 pole filter?
    This could let you get better sounds removing more noise.

    Regarding your code, I would discourage using MACROs with the #define preprocessor directive. Macros can hide bugs. In your case I would have created a function.
    Don't speed up the code before is not even working, Optimizations must be done if required.

    regarding the for ( ;; ) infinite loop I would have used while (1) or even better:

    #define TRUE= 0x01

    while (TRUE)

    ...but these are just some code practices and habits.


  8. Vaughanabe13

    Active Member

    May 4, 2009
    What is the advantage to using while(1) over for(;;) ?? Don't they do the exact same thing?
  9. THE_RB

    AAC Fanatic!

    Feb 11, 2008
    while(1) uses proper C syntax and is guaranteed to compile.

    for( ; ; ) just happens to compile to the same result... probably. ;)
  10. mauro.laurenti

    Active Member

    May 8, 2009
    Yes they do, indeed.


    while (1)

    it's a clear way to say, I'm not changing anything in the loop which will be always passing the test.

    when you read for ( ; ; ) is not as clear. Furthermore for ( ; ; ) is a powerful instruction and its translation in assembly is more complex than a while ( ), this means you can save bytes. This is a kind of Optimization which is coming indirectly and for free by a simple code style.

    In c and c++ codes such as firefox and tunderbird you generally find while (1) instead of for ( ; ; ). If most of the people use something that could be done also in different ways but without advantages, follow the people.
    More people will understand you with less effort.

    If most of the people are doing something and you can do better, do your way but explain it.