I am merging two pcm data and the resultant pcm is having additional noise of grrrrrrrrrr. My code is :
int main(void)
{
FILE *rCAudio;
FILE *raudio;
FILE *wtest;
rCAudio=fopen("Audio1.pcm","rb"); //Reading first pcm file
if(rCAudio==NULL)
cout<<"Errr";
raudio=fopen("Audio2.pcm","rb"); //Reading second pcm file
if(raudio==NULL)
cout<<"Errr";
fopen_s(&wtest,"AudioMerge.pcm","ab"); // Writing final pcm file
short* first= new short[1792];;
short* second= new short[1792];;
short* merge = new short[1792];
short sample1,sample2;
while(1)
{
fread(first,2,1792,rCAudio);
fread(second,2,1792,raudio);
for(int j=0;j<1792;j++)
{
sample1 = first[j];
sample2 = second[j];
int mixedi=(int)sample1 + (int)sample2;
if (mixedi>32767) mixedi=32767;
if (mixedi<-32768) mixedi=-32768;
merge[j] =(short)mixedi;
}
fwrite(merge,2,1972,wtest);
}
}
I got the solution , the problem was:
I have written Audio1.pcm with 4096 bytes at a time in BYTE and Audio2.pcm with 4096 bytes at a time in BYTE. But i was reading 1972 bytes at a time in short.
So i corrected it by reading 4096 bytes at a time in BYTE and save by third merge file with 4096 bytes at a time in BYTE.
Related
I am trying to transmit audio using CAN FD and the data format it sends it is in uint8_t, when the sample I take from the microphone with the ADC is an uint32_t. Will I have any problem trying to insert this uint8_t data into a wav after being transmitted with CAN FD? I have tried to create .wav with the data but I only hear noise.
This is and image of a .wav file I create with a simple 64 byte CAN FD message.
.wav file
I know only introducing 64 bytes is a really small amount for a .wav but I dont know how to concatenate more data into a buffer in order to get bigger files.
Thiis the function I use to create my .wav
void write_little_endian(unsigned int word, int num_bytes, FILE *wav_file)
{
uint16_t buf;
while(num_bytes>0)
{ buf = word & 0xff;
fwrite(&buf, 1,1, wav_file);
num_bytes--;
word >>= 8;
}
}
void write_wav(char * filename, unsigned long num_samples, short int * data, int s_rate)
{
FILE* wav_file;
unsigned int sample_rate;
unsigned int num_channels;
unsigned int bytes_per_sample;
unsigned int byte_rate;
unsigned long i; /* counter for samples */
num_channels = 1; /* monoaural */
bytes_per_sample = 1;
if (s_rate<=0) sample_rate = 16000;
else sample_rate = (unsigned int) s_rate;
byte_rate = sample_rate*num_channels*bytes_per_sample;
wav_file = fopen(filename, "wb");
assert(wav_file); /* make sure it opened */
/* write RIFF header */
fwrite("RIFF", 1, 4, wav_file);
write_little_endian(36 + bytes_per_sample* num_samples*num_channels, 4, wav_file);
fwrite("WAVE", 1, 4, wav_file);
/* write fmt subchunk */
fwrite("fmt ", 1, 4, wav_file);
write_little_endian(16, 4, wav_file); /* SubChunk1Size is 16 */
write_little_endian(1, 2, wav_file); /* PCM is format 1 */
write_little_endian(num_channels, 2, wav_file);
write_little_endian(sample_rate, 4, wav_file);
write_little_endian(byte_rate, 4, wav_file);
write_little_endian(num_channels*bytes_per_sample, 2, wav_file); /* block align */
write_little_endian(8*bytes_per_sample, 2, wav_file); /* bits/sample */
/* write data subchunk */
fwrite("data", 1, 4, wav_file);
write_little_endian(bytes_per_sample* num_samples*num_channels, 4, wav_file);
for (i=0; i< num_samples; i++)
{ write_little_endian((unsigned int)(data[i]),bytes_per_sample, wav_file);
}
fclose(wav_file);
}
I send this command to call it and I receive what I will post on the next image:
write_wav("test.wav", 44100, (short int *)buffer, 44100);
.wav with a bigger buffer of 44100 samples of uint16_t
But when I play this file, the audio is just beeps and noise, not my voice
:(
Update = After some tries, I think the problem resides in the data I send throught the CAN FD. I have watched the data inside another .wav and the format doesnt look similar to mines. I dont know how to send uint32_t data that I acquire with the ADC through a uint8_t format CAN FD data field. I have tried casting the data but I dont know how to prepare it for the .wav Can anyone help me with that? Should I send it with uint8_t and then back to uin32_t before inserting it into a .wav?
It depends on what sample rate you need. At 5 Mbps baudrate, 11 bit identifiers, 64 byte data, the effective payload will be transferred at roughly 4 Mbps (this can be calculated fairly exactly). The MCU will need a bit of execution time to process it, but it's probably negligible. That is, the real time spec by far exceeds at what sample rates the human ear stop hearing any differences at. Your problems aren't related to picking CAN FD as hardware/datalink layer. You could likely do this with classic CAN just fine too.
Obviously don't transfer files but raw data. It only needs to be turned into a file before playing.
I have an application that playback audio. It takes encoded audio data over RTP and decode it to 16bit array. The decoded 16bit array is converted to 8 bit array (byte array) as this is required for some other functionality.
Even though audio playback is working it is breaking continuously and very hard to recognise audio output. If I listen carefully I can tell it is playing the correct audio.
I suspect this is due to the fact I convert 16 bit data stream into a byte array and use the write(byte[], int, int, AudioTrack.WRITE_NON_BLOCKING) of AudioTrack class for audio playback.
Therefore I converted the byte array back to a short array and used write(short[], int, int, AudioTrack.WRITE_NON_BLOCKING) method to see if it could resolve the problem.
However now there is no audio sound at all. In the debug output I can see the short array has data.
What could be the reason?
Here is the AUdioTrak initialization
sampleRate =AudioTrack.getNativeOutputSampleRate(AudioManager.STREAM_MUSIC);
minimumBufferSize = AudioTrack.getMinBufferSize(sampleRate, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT);
audioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, sampleRate,
AudioFormat.CHANNEL_OUT_STEREO,
AudioFormat.ENCODING_PCM_16BIT,
minimumBufferSize,
AudioTrack.MODE_STREAM);
Here is the code converts short array to byte array
for (int i=0;i<internalBuffer.length;i++){
bufferIndex = i*2;
buffer[bufferIndex] = shortToByte(internalBuffer[i])[0];
buffer[bufferIndex+1] = shortToByte(internalBuffer[i])[1];
}
Here is the method that converts byte array to short array.
public short[] getShortAudioBuffer(byte[] b){
short audioBuffer[] = null;
int index = 0;
int audioSize = 0;
ByteBuffer byteBuffer = ByteBuffer.allocate(2);
if ((b ==null) && (b.length<2)){
return null;
}else{
audioSize = (b.length - (b.length%2));
audioBuffer = new short[audioSize/2];
}
if ((audioSize/2) < 2)
return null;
byteBuffer.order(ByteOrder.LITTLE_ENDIAN);
for(int i=0;i<audioSize/2;i++){
index = i*2;
byteBuffer.put(b[index]);
byteBuffer.put(b[index+1]);
audioBuffer[i] = byteBuffer.getShort(0);
byteBuffer.clear();
System.out.print(Integer.toHexString(audioBuffer[i]) + " ");
}
System.out.println();
return audioBuffer;
}
Audio is decoded using opus library and the configuration is as follows;
opus_decoder_ctl(dec,OPUS_SET_APPLICATION(OPUS_APPLICATION_AUDIO));
opus_decoder_ctl(dec,OPUS_SET_SIGNAL(OPUS_SIGNAL_MUSIC));
opus_decoder_ctl(dec,OPUS_SET_FORCE_CHANNELS(OPUS_AUTO));
opus_decoder_ctl(dec,OPUS_SET_MAX_BANDWIDTH(OPUS_BANDWIDTH_FULLBAND));
opus_decoder_ctl(dec,OPUS_SET_PACKET_LOSS_PERC(0));
opus_decoder_ctl(dec,OPUS_SET_COMPLEXITY(10)); // highest complexity
opus_decoder_ctl(dec,OPUS_SET_LSB_DEPTH(16)); // 16bit = two byte samples
opus_decoder_ctl(dec,OPUS_SET_DTX(0)); // default - not using discontinuous transmission
opus_decoder_ctl(dec,OPUS_SET_VBR(1)); // use variable bit rate
opus_decoder_ctl(dec,OPUS_SET_VBR_CONSTRAINT(0)); // unconstrained
opus_decoder_ctl(dec,OPUS_SET_INBAND_FEC(0)); // no forward error correction
Let's assume you have a short[] array which contains the 16-bit one channel data to be played.
Then each sample is a value between -32768 and 32767 which represents the signal amplitude at the exact moment. And 0 value represents a middle point (no signal). This array can be passed to the audio track with ENCODING_PCM_16BIT format encoding.
But things are going weird when playing ENCODING_PCM_8BIT is used (See AudioFormat)
In this case each sample encoded by one byte. But each byte is unsigned. That means, it's value is between 0 and 255, while 128 represents the middle point.
Java has no unsigned byte format. Byte format is signed. I.e. values -128...-1 will represent actual values of 128...255. So you have to be careful when converting to the byte array, otherwise it will be a noise with barely recognizable source sound.
short[] input16 = ... // the source 16-bit audio data;
byte[] output8 = new byte[input16.length];
for (int i = 0 ; i < input16.length ; i++) {
// To convert 16 bit signed sample to 8 bit unsigned
// We add 128 (for rounding), then shift it right 8 positions
// Then add 128 to be in range 0..255
int sample = ((input16[i] + 128) >> 8) + 128;
if (sample > 255) sample = 255; // strip out overload
output8[i] = (byte)(sample); // cast to signed byte type
}
To perform backward conversion all should be the same: each single sample to be converted to exactly one sample of the output signal
byte[] input8 = // source 8-bit unsigned audio data;
short[] output16 = new short[input8.length];
for (int i = 0 ; i < input8.length ; i++) {
// to convert signed byte back to unsigned value just use bitwise AND with 0xFF
// then we need subtract 128 offset
// Then, just scale up the value by 256 to fit 16-bit range
output16[i] = (short)(((input8[i] & 0xFF) - 128) * 256);
}
The issue of not being able to convert data from byte array to short array was resolved when used bitwise operators instead of using ByteArray. It could be due not setting the correct parameters in ByteArray or it is not suitable for such conversion.
Nevertheless implementing conversion using bitwise operators resolved the problem. Since the original question has been resolved by this approach, please consider this as the final answer.
I will raise a separate topic for playback issue.
Thank you for all your support.
I am reading a wav file and trying to play it with alsa api using writei() method.
Wav file header has following values
Audio Format: 1 (PCM)
Num Channels: 1
Sample Rate: 11025
Byte Rate: 11025
Block Align: 1
Bits Per Sample: 8
Subchunk2 id: 0x61746164
Subchunk2 Size: 24569
I did not change buffer size or period size. Period size for my hw device is 4096 (I read it using snd_pcm_hw_params_get_period_size() )
Call to writei() looks like
//buff_size = period_size * size of each frame = 4096 * 1 bytes;
int16_t* buff = (int16_t *) malloc(buff_size);
for(i = 0; i < 6; ++i){
memcpy(buff, &samples[i*period_size], buff_size);
if (err = snd_pcm_writei(pcm, buff, period_size) == -EPIPE) {
printf("XRUN.\n");
snd_pcm_prepare(pcm);
} else if (err < 0) {
printf("ERROR. Can't write to PCM device. %s\n", snd_strerror(err));
}
}
As wav file is 8-bit PCM Mono, frame size is 1 byte and so this file's data size is 24569 frames. Using default period_size, buffer size for writei() = period_size * channels = 4096.
So I need 6 calls to writei() to play the entire file. But when I do that I cannot hear anything. Any idea what is wrong?
I've discovered it is dangerous to assume that all PCM wav audio files have 44 bytes of header data before the samples begin. Though this is common, many applications (ffmpeg for example), will generate wavs with a 46-byte header and ignoring this fact while processing will result in a corrupt and unreadable file. But how can you detect how long the header actually is?
Obviously there is a way to do this, but I searched and found little discussion about this. A LOT of audio projects out there assume 44 (or conversely, 46) depending on the authors own context.
You should be checking all of the header data to see what the actual sizes are. Broadcast Wave Format files will contain an even larger extension subchunk. WAV and AIFF files from Pro Tools have even more extension chunks that are undocumented as well as data after the audio. If you want to be sure where the sample data begins and ends you need to actually look for the data chunk ('data' for WAV files and 'SSND' for AIFF).
As a review, all WAV subchunks conform to the following format:
Subchunk Descriptor (4 bytes)
Subchunk Size (4 byte integer, little endian)
Subchunk Data (size is Subchunk Size)
This is very easy to process. All you need to do is read the descriptor, if it's not the one you are looking for, read the data size and skip ahead to the next. A simple Java routine to do that would look like this:
//
// Quick note for people who don't know Java well:
// 'in.read(...)' returns -1 when the stream reaches
// the end of the file, so 'if (in.read(...) < 0)'
// is checking for the end of file.
//
public static void printWaveDescriptors(File file)
throws IOException {
try (FileInputStream in = new FileInputStream(file)) {
byte[] bytes = new byte[4];
// Read first 4 bytes.
// (Should be RIFF descriptor.)
if (in.read(bytes) < 0) {
return;
}
printDescriptor(bytes);
// First subchunk will always be at byte 12.
// (There is no other dependable constant.)
in.skip(8);
for (;;) {
// Read each chunk descriptor.
if (in.read(bytes) < 0) {
break;
}
printDescriptor(bytes);
// Read chunk length.
if (in.read(bytes) < 0) {
break;
}
// Skip the length of this chunk.
// Next bytes should be another descriptor or EOF.
int length = (
Byte.toUnsignedInt(bytes[0])
| Byte.toUnsignedInt(bytes[1]) << 8
| Byte.toUnsignedInt(bytes[2]) << 16
| Byte.toUnsignedInt(bytes[3]) << 24
);
in.skip(Integer.toUnsignedLong(length));
}
System.out.println("End of file.");
}
}
private static void printDescriptor(byte[] bytes)
throws IOException {
String desc = new String(bytes, "US-ASCII");
System.out.println("Found '" + desc + "' descriptor.");
}
For example here is a random WAV file I had:
Found 'RIFF' descriptor.
Found 'bext' descriptor.
Found 'fmt ' descriptor.
Found 'minf' descriptor.
Found 'elm1' descriptor.
Found 'data' descriptor.
Found 'regn' descriptor.
Found 'ovwf' descriptor.
Found 'umid' descriptor.
End of file.
Notably, here both 'fmt ' and 'data' legitimately appear in between other chunks because Microsoft's RIFF specification says that subchunks can appear in any order. Even some major audio systems that I know of get this wrong and don't account for that.
So if you want to find a certain chunk, loop through the file checking each descriptor until you find the one you're looking for.
The trick is to look at the "Subchunk1Size", which is a 4-byte integer beginning at byte 16 of the header. In a normal 44-byte wav, this integer will be 16 [10, 0, 0, 0]. If it's a 46-byte header, this integer will be 18 [12, 0, 0, 0] or maybe even higher if there is extra extensible meta data (rare?).
The extra data itself (if present), begins in byte 36.
So a simple C# program to detect the header length would look like this:
static void Main(string[] args)
{
byte[] bytes = new byte[4];
FileStream fileStream = new FileStream(args[0], FileMode.Open, FileAccess.Read);
fileStream.Seek(16, 0);
fileStream.Read(bytes, 0, 4);
fileStream.Close();
int Subchunk1Size = BitConverter.ToInt32(bytes, 0);
if (Subchunk1Size < 16)
Console.WriteLine("This is not a valid wav file");
else
switch (Subchunk1Size)
{
case 16:
Console.WriteLine("44-byte header");
break;
case 18:
Console.WriteLine("46-byte header");
break;
default:
Console.WriteLine("Header contains extra data and is larger than 46 bytes");
break;
}
}
In addition to Radiodef's excellent reply, I'd like to add 3 things that aren't obvious.
The only rule for WAV files is the FMT chunk comes before the DATA chunk. Apart from that, you will find chunks you don't know about at the beginning, before the DATA chunk and after it. You must read the header for each chunk to skip forward to find the next chunk.
The FMT chunk is commonly found in 16 byte and 18 byte variations, but the spec actually allows more than 18 bytes as well.
If the FMT chunk' header size field says greater than 16, Bytes 17 and 18 also specify how many extra bytes there are, so if they are both zero, you end up with an 18 byte FMT chunk identical to the 16 byte one.
It is safe to read in just the first 16 bytes of the FMT chunk and parse those, ignoring any more.
Why does this matter? - not much any more, but Windows XP's Media Player was able to play 16 bit WAV files, but 24 bit WAV files only if the FMT chunk was the Extended (18+ byte) version. There used to be a lot of complaints that "Windows doesn't play my 24 bit WAV files", but if it had an 18 byte FMT chunk, it would... Microsoft fixed that sometime during the early days of Windows 7, so 24 bit with 16 byte FMT files work fine now.
(Newly added) Chunk sizes with odd sizes occur quite often. Mostly seen when a 24 bit mono file is made. It is unclear from the spec, but the chunk size specifies the actual data length (the odd value) and a pad byte (zero) is added after the chunk and before the start of the next chunk. So chunks always start on even boundaries, but the chunk size itself is stored as the actual odd value.
I am writing a program and I need to access some information in the boot sector about the FAT32 file system that I have mounted.
Here is what I did, fully commented.
int main (void) {
unsigned short *i; //2 byte unsigned integer pointer
char tmp[1024]; //buffer
int fd; //file descriptor from opening device
fd = open("/dev/sdf", O_RDONLY); //open the device file
lseek(fd, 14, SEEK_SET); //set offset to 14 (0x0E), i.e. storing "no. of reserved sectors" of the FAT32 system
read(fd, tmp, 2); //read off 2 bytes, "no. of reserved sectors" is represented by 2 bytes
i = &tmp; //point j at those 2 bytes
printf("*j: %d\n", *j); //print *j out
close(fd); //close device
return 0;
}
The output of *i is 38, which is nonsense. I formatted the file system with mkfs.vfat. I set the "no. of reserved sectors" to 32.
What I have tried:
i = (unsigned short *) &tmp, do a casting, this removes the warning when I compile, but doesn't help
read(fd, tmp, 512), load the whole boot sector (512 bytes) into tmp, then read from the buffer, but doesn't help, result still 38 though.
fiddle with the offset, i.e. change 14 to 13 or 15, in case I get the index wrong. It prints out 9744 for 13 and 512 for 15 respectively, so doesn't work.
I'm not sure whether I'm doing it the right way. Can someone please point me in the right direction?
Thanks in advance,
Felastine.
Try running:
$ dd if=/dev/sdf of=/tmp/x.bin bs=512 count=1
And then:
$ hd /tmp/x.bin
Or
$ od -tx2 /tmp/x.bin
And post the first lines.
Chances are that your fattools are adding 6 extra reserved sectors of their own. And then they substract them before showing the data.
unsigned short *i; //2 byte unsigned integer pointer
char tmp[1024];
[...]
i = &tmp; //point j at those 2 bytes
tmp is char[], &tmp something of order char**.
Think again, you don't want the & here.