Wanted: Sound chip interfaced with pic

[xnihilo]

Hi,

I've already bookmarked a page related to that stuff and a post from you, intending to have a look later.
So I can interface it directly to a pic then?

[Normnet]

Interfaced directly from PIC with MSSP SPI (fastest).

Web page http://www.hickorytech.net/~normnet/

Norm

[skimask]

I id NOT find a good interfacing example Mr SkimaskKnowsEverytging.
Yes I have the datasheet.
Yes, I am using to create a placeholder for the gunshot sound in my code but it sucks.

Funny... Google pulls up a fair amount of interfaces for me. And the VS1001 datasheet show most everything needed.

A turd... Nice...
I need a REALISTIC gunshot, that's all. Unless you have a replacement solution for such noise, your posts are somehow irrelevant... It looks like you need to have something to say to any post on this forum...

Look pal, I'm just pointing out the fact that sometimes...SOMETIMES...a person overdoes a project by a whole load and wastes a lot of money and effort for perfection when the end result doesn't justify it.

Do you know what is needed (software and hardware) to use ISD chips?

Again, Google finds a few decent examples of ISD usage with an MCU.

Do you have an idea? MP3 with a little amplifier might do the trick, that's why I thought aout that..

How much does a VS1001 cost? How much does a decent amplifier cost? How much does a decent speaker cost? How much tooling to make a good PCB? How much room in a box? Is it really viable?

I need to record my sound (or transfer it from my pc).
I need interfacing example to a PIC16F690 and PBP code.

Need need need. There are examples out there. They might not all be for exactly PICs and PBP, but they aren't that different from one to the next.

Jist of the story...how you even tried the SOUND command yet? I had a play with it a couple of days ago just to see if I was on crack, talking smack, or whatever. I think the sounds came out pretty good with the example shown in the PBP manual, nothing more. A bit more of a better filter, maybe a bit of tweaking and finding the right sound frequencies/duration, I'd think that SOUND could produce something really decent.

[mister_e]

ISD chip could do the job, some have built-in amplifier, A DsPIC with nothing else as well

I already hard-coded some WAV sounds. A bit waste of time... but fun to do and don't require nothing else on board... just a small amplifier such as TS4962 (one of my favourite for really small size amp, really neat), opamp+transistors or this 650 years old LM386

And this also bring Roman Sound BitCoder solution. Could be fine... worth you try it.

Quadravox programmer for ISD is one solution for mass production.

For MP3, i would no longer use this about to be obsoleted VS1001, VS1011 would be a better choice.

[Normnet]

So, as i need only a player for one sound file, idealy I would need on one hand a complete application for recording/dumping the sound to m25p32 chips and on the other hand an application with a pic containing only a small player routine.

Yes.
Perhaps the play routine would fit on demo version or port to PBP.

I saw there are 4 sound formats supported, i guess i would only need... uh... 16bits uncompressed?? Ulaw, adpcm,... will reduce sound quality, won't they?.

16bits uncompressed is the best (CD quality), others down sample for increased play length.

From what I've seen in the code, you press shortly so it plays all stored files one after another, a press again stops the play and pressing longer fast forwards?

Yes.
I would use the in code call to play lines in the mainloop:
If sPLAY_BUTTON = 1 Then
iIN_PROGRAM_FILE_PLAY_SET = 1
wIN_PROG_FILE_TO_PLAY = 1
Endif
Play will also end if sPLAY_BUTTON = 0 in the MEM_CHIP_PLAY_16BIT sub.
This means you can start wave file by externally setting the PLAY_BUTTON pin high and stop by setting sPLAY_BUTTON pin low.

your code sends the data byte from memory to dac? Is it that 'simple'??? is the sound modified somehow between the m25p32 and the dac??

The data has already been processed from the original wave file by the PC program.
Just a read of 2 sequential bytes from M25P32 and a send of 2 bytes to DAC required.
I call it a raw file.

Producing sound with a pic is sending sound bytes at a specific 'sampling' rate to a dac? Then what is the 8bits/16bits sound parameter for?

16 bits (0-65535) increases the number of steps of volume available per sample compared to 8 bits (0-255),
Increases the quality or precision with the sampling rates being equal.
16 bits is CD quality.

I wonder if having the very short sound file (about 1s) stored in the pic internal Eeprom would not work if i feed it to the dac without the need for a serial eeprom...

One second of CD quality requires 44.2k word samples.
The largest eeprom in the PIC18 series is only 1024 bytes.
Even if loaded to ram the PIC18F4620 can hold only 15 128 element word arrays or only 1.92k of word samples.
Audio memory requires massive capacity and high speed.

Norm

[xnihilo]

Hello Norm,

I wish to thank you for all your answers. Clear and it answers exactly my questions.

When you say: "The data has already been processed from the original wave file by the PC program."
-> you mean by your program that dumps the sound file to the memory chip or by the program that recorded/converted the sound? In other words, would the sound file (wave, 44KHz, 16 bits) I found in a game sound directory be ready to be stored in the memory chip? Can I transfer the wave file 'bit per bit' into a memory chip or does the file need to be modified to be used by the dac? I guess there is a header, a trailer, a checksum and stuff like this I should get rid of first. I will read the wave file specs...

"16 bits (0-65535) increases the number of steps of volume available per sample compared to 8 bits (0-255),"
-> Right, aft(er posting the questions I googled to find the answer. I undesrtand now. Thanks.

"The largest eeprom in the PIC18 series is only 1024 bytes.
Even if loaded to ram the PIC18F4620 can hold only 15 128 element word arrays or only 1.92k of word samples.
Audio memory requires massive capacity and high speed."
-> Yes, I understand. Maybe I could try an external EEPROM (I already use one for my project), I have to check if it has a SPI interface and if it can be accessed at a frequency compatible with the sound frequency.


I found the microchip 25AA1024 1Mbits SPI bus serial EEPROM. It has 246 bytes page size, and a 20MHz clock speed.
It could store my 44K words of my 1s sound at 16bits 44KHz.
I guess it could replace the M25P32 memory chip...

[Normnet]

When you say: "The data has already been processed from the original wave file by the PC program."
-> you mean by your program that dumps the sound file to the memory chip or by the program that recorded/converted the sound? In other words, would the sound file (wave, 44KHz, 16 bits) I found in a game sound directory be ready to be stored in the memory chip? Can I transfer the wave file 'bit per bit' into a memory chip or does the file need to be modified to be used by the dac? I guess there is a header, a trailer, a checksum and stuff like this I should get rid of first. I will read the wave file specs...

The PC program converts from wave format to sequential bytes and sends to memory chip.
Must be modified.
PC program also adds CRC for 115k serial transfer.
I believe the PC program source code is included in my website download.

Norm

[skimask]

Can I transfer the wave file 'bit per bit' into a memory chip or does the file need to be modified to be used by the dac?

Which DAC would that be?
Not too many PICs out there have DACs.

Another thought for you...
44.1Khz sample rate * 16 bits * single channel (ignoring stereo for the moment)

705,600 bps shift rate... Doable by a PIC, assuming you use the right crystal and the right baud rate dividers...
88,200 bytes per second total transfer rate from EEPROM to DAC thru the PIC.
Again, doable by a PIC since it's the same thing.

Ok, set up the SPI at the proper bit rate to shift data out of the EEPROM sequentially...Done...
Catch an interrupt every 8 bits to grab byte data from the SPI...
Catch every other interrupt after grabbing 2 bytes to send the 2 bytes out to the DAC.
Is this going to be a serial DAC or a parallel DAC? 16 bit DAC or 8 bit DAC?
Serial DAC...well, your SPI is already tied up grabbing data from the EEPROM, unless you're using a large PIC with 2 SPI modules. So, do you have enough PIC cycles left over to shift that data in and/or out using the firmware? Using Shiftin and/or Shiftout, you aren't going to have a lot of cycles leftover for much at all.
Parallel DAC...Your SPI is still tied up grabbing data from the EEPROM. Do you have enough pins left over to pump parallel data out to the DAC (at minimum a 28 pin PIC with practically no pins leftover to do anything)? Not to mention enough cycles left over to process any other inputs/outputs that your project requires?