I made some changes to the above program. This is doing exactly the same as above, but is much faster. I went from about 10% CPU usage to about 4%.

        //Pre-Calculate the FIR coefficients for Hamming Window with gain
        for (int i = 0; i < 64; i++) {
            fir64Coff[i] = (double_t)((1 << 10) - 1);

            //Hanning Window
            fir64Coff[i] *= 0.5f * (1.0f - cos((2.0f * M_PI * (double_t)i) / (64.0f - 1.0f)));
        }

        //Precalculate the sums for byte-bit combinations
        precalculated = malloc(sizeof(double_t *) * 8);

        for (uint8_t i = 0; i < 8; i++) {
            precalculated[i] = malloc(sizeof(double_t) * 256);
            
            for (uint16_t j = 0; j < 256; j++) {
                uint8_t test = j;
                double_t sum = 0;

                uint8_t coefficientIndex = 8 * i;

                for (uint8_t k = 0; k < 8; k++) {
                    if ((test & 0x01) == 0x01) {
                        sum += fir64Coff[coefficientIndex];
                    }
                    else {
                        sum -= fir64Coff[coefficientIndex];
                    }
                    
                    test >>= 1;

                    coefficientIndex++;
                }
                
                precalculated[i][j] = sum;
            }
        }

And the play routine:

- (uint64_t)getBytes:(void *)buffer sampleCount:(long unsigned)count {

    if (mIsEndOfSong) {
        return 0;
    }

    [mutex lock];

    int16_t *sampleBuffer = (int16_t *)buffer;
    
    for (uint32_t currentSample = 0; currentSample < count; currentSample++) {

        int64_t sumLeft = 0;
        int64_t sumRight = 0;

        for (uint8_t i = 0; i < 8; i++) {
            if (currentBufferPos >= blockSize) {
                if (![self readChunk]) {
                    [mutex unlock];
                    return currentSample;
                }
            }

            sumLeft += precalculated[i][bufferLeft[currentBufferPos]];
            sumRight += precalculated[i][bufferRight[currentBufferPos]];
            
            currentBufferPos++;
        }
        
        sampleBuffer[(currentSample << 1) + 0] = (int16_t)sumLeft;
        sampleBuffer[(currentSample << 1) + 1] = (int16_t)sumRight;
    }
    
    [mutex unlock];
    return count;
}

You seem to be using bad and/or nonsensical filters.

Ideally, you want to run your PDM waveform through an ideal lowpass filter with cutoff rate equal to the target Nyquist frequency (for CD audio, 22050 Hz): the corresponding FIR coefficients are an infinitely long sinc waveform.

In the real world, your options include

• exact computation for a periodic signal using a Fourier transform
• hopefully cheap, but difficult to design, approximation by IIR filters (not recommended for a beginner, probably not recommended for anyone).
• decent approximation with FIR filters: 64 coefficients are VERY few. The correct way to use window functions is multiplying them by a sinc function to obtain a "windowed sinc function" that sounds as good as possible for a given number of coefficients.
  Your "lowPassFIR" function appears to be a rather correct starting point, but coefficients are constant and they should be kept in an array for performance reasons (sparing sine evaluations and allowing parallel computations).

You shouldn't perform the ugly and wrong filtering by bell-shaped functions at the beginning. Conceptually, resampling from 2822400 to 44100 Hz follows lowpass filtering; you can simply compute one output in 64 of the 2822400 Hz filter from the original values, without inappropriate preprocessing.

Well I think I can see a simple error which might be the problem.

if (currentBufferPos >= blockSize)
{
       if (![self readChunk])    // load in next block
       {
             [mutex unlock];
              return currentSample;
       }
}

So say your block size is 4096, when currentBufferPos == 4096 you read the next buffer, ok

      sumLeft += precalculated[i][bufferLeft[currentBufferPos]];                 // currentBufferPos == 4096 !!!!
      sumRight += precalculated[i][bufferRight[currentBufferPos]];            // currentBufferPos == 4096 !!!!
            
      currentBufferPos++;                                                                          // currentBufferPos == 4097

It could be that currentBufferPos is reset in the code that reads in the new block, but if not it definetly looks wrong.

Well I think I can see a simple error which might be the problem.

if (currentBufferPos >= blockSize)
{
       if (![self readChunk])    // load in next block
       {
             [mutex unlock];
              return currentSample;
       }
}

So say your block size is 4096, when currentBufferPos == 4096 you read the next buffer, ok

      sumLeft += precalculated[i][bufferLeft[currentBufferPos]];                 // currentBufferPos == 4096 !!!!
      sumRight += precalculated[i][bufferRight[currentBufferPos]];            // currentBufferPos == 4096 !!!!
            
      currentBufferPos++;                                                                          // currentBufferPos == 4097

It could be that currentBufferPos is reset in the code that reads in the new block, but if not it definetly looks wrong.

Oh no, I didn't include that here, but currentBufPos is reset to 0 inside the same function that refills the buffers. I would probably have more serious errors, if I didn't reset the buffer pointer.

I am sure LorenzoGatti is closer to what my problem is, which is what I suspect in the first place.

You seem to be using bad and/or nonsensical filters.

Ideally, you want to run your PDM waveform through an ideal lowpass filter with cutoff rate equal to the target Nyquist frequency (for CD audio, 22050 Hz): the corresponding FIR coefficients are an infinitely long sinc waveform.

In the real world, your options include

• exact computation for a periodic signal using a Fourier transform
• hopefully cheap, but difficult to design, approximation by IIR filters (not recommended for a beginner, probably not recommended for anyone).
• decent approximation with FIR filters: 64 coefficients are VERY few. The correct way to use window functions is multiplying them by a sinc function to obtain a "windowed sinc function" that sounds as good as possible for a given number of coefficients.
  Your "lowPassFIR" function appears to be a rather correct starting point, but coefficients are constant and they should be kept in an array for performance reasons (sparing sine evaluations and allowing parallel computations).

You shouldn't perform the ugly and wrong filtering by bell-shaped functions at the beginning. Conceptually, resampling from 2822400 to 44100 Hz follows lowpass filtering; you can simply compute one output in 64 of the 2822400 Hz filter from the original values, without inappropriate preprocessing.

I had a feeling that 64 coefficients were a bit few. I tried with a lot more earlier, but with a different approach than I did here, and the result I got when I tried was more and more smearing (=dull sound) the more coefficients I used, and more crisp sound with fewer coefficients.

I will take your advice and redesign as you are suggesting at the end. It fits with the idea that a low pass filter is all you need to decode the data, something I am obviously not doing here. Thank you for pointing me in the right direction. How many coefficients do you think would be sane?

Edit: I agree to stay away from IIR filters. I would probably design one that would blow my speakers... ;)

Edit2: Thank you for mentioning parallel computations, that didn't even occur to me! That would probably give me a little bit more room to wiggle, if I would be short on processing time.

Edit3: I know that the coefficients are constants, and I am actually treating them as such. In my thinking, since I am working on 1-bit data, I don't need to multiply any coefficients, just add them from the precompiled values.

How many coefficients do you think would be sane?

As many as possible; it depends on your budget of multiplications and additions per output sample (which is likely to be in the tens or hundreds of thousands on a modern CPU).

What is your intended application? Do you need to decode SACD audio in real time, as opposed to performing a high-quality conversion to a more usable PCM format in advance? Are you doing other tasks while converting audio?

Another issue: extending the lowpass filter introduces a delay between input and output, which can be compensated in batch processing (just offset buffers by the correct number of samples for mixing with other sources and/or cut the initial silence in output) but not always in music reproduction or similar realtime applications (you might be unable to begin playing samples in advance).

How many coefficients do you think would be sane?

As many as possible; it depends on your budget of multiplications and additions per output sample (which is likely to be in the tens or hundreds of thousands on a modern CPU).

What is your intended application? Do you need to decode SACD audio in real time, as opposed to performing a high-quality conversion to a more usable PCM format in advance? Are you doing other tasks while converting audio?

Another issue: extending the lowpass filter introduces a delay between input and output, which can be compensated in batch processing (just offset buffers by the correct number of samples for mixing with other sources and/or cut the initial silence in output) but not always in music reproduction or similar realtime applications (you might be unable to begin playing samples in advance).

I am actually trying to decode SACD audio in real time, and it is a project just for fun and learning experience. Writing everything from scratch when there are other products that does the job for you. Actually, my app is turning into a nice and light audio player that can currently play WAV, FLAC, MOD, SACD and I am also working on MP3, and it can handle a massive library. The GUI is not great, but it is working. I am planning to throw away the GUI and go for a web-view instead, but I am not completely sure yet. I have much more plans in the future for other nice features too, but the essence is that I want the application to be responding fast, although that is not always possible when you have a system that stalls while waiting for I/O all the time, but I have implemented things to make that experience better, like loading things in the background and not switching to a new song until the other song is ready (showing an indicator if the system is lagging for more than half a second so the user doesn't think the application is hanging, or you end up losing the beginning of the next song due to buffer under-run.)

regarding SACD, playback is actually sounding pretty good, if you can ignore the hissing noise. It is not the kind of unpleasant noise, more like a soft low untuned treble radio out of tune-white noise. The noise has an "analog" quality, if I can put it like that. Of course I am going to remove that, but I am surprised it sounds as good as it does with my flawed FIR filtering. My goal is to make the sound as good as it possibly can get in real time. That also means supporting 192 kHz and such in the future, but for now I am a bit scared of the aliasing artefacts that I have read can destroy audio equipment, if you are not using a proper low pass filter. I think 44.1 kHz is good for a pilot.

I am not doing other tasks while converting Audio, but the application should ideally work together with use of other application on the host OS.

If I understand you correctly, you are saying that using a FIR filter with a lot of coefficients will introduce latency in the playback of the audio stream. I am not sure if I am too concerned with that, unless the latency gets too big. I would guess 0.5-1 second would be acceptable, but that is just a number I picked arbitrarily. I know that in realtime applications, you need to be aware of causality, but is it not real time like in a live gig, it is more like files on a hard drive, so some tricks would probably be possible with a fast computer. (Thinking about the same discarding of silence that you mentioned.)

Fortunately, regarding my budget, as I mentioned, since it is a 1-bit stream, I think I can get away with multiplications using a lookup table. I would only multiply by 1 and -1 anyway, which is a waste to actually perform such multiplication.

Edit: Weirdly some songs have a lot of noise, but other songs I can barely hear the noise. This fact makes me think that the noise I am hearing is aliasing for not filtering out the high frequencies. It seems to be dependent on how the SACD is produced if I hear a lot of noise or not.

Also, I find it encouraging that playback can be this good on my turtle-computer, using only 4% CPU. FLAC decoding easily consumes more CPU than that, although implementing small and simple things like pre-buffering instead of reading directly from file, made decoding way much faster. (30% down to 6-8% CPU.) I found that to be acceptable for now, although I will try to optimise more when I feel the product is nearing completion.

To Stainless: There is one thing I haven't told you... That there actually IS a bug in the code regarding loading the buffer, although it shouldn't matter unless the bitstream is malformed. If I prematurely reach end of file, the last buffer will be discarded. (Say you only read 100 bytes instead of 2 * 4096 bytes before reaching end of file, you still have 100 bytes to process, but it will be discarded.) Edit again: Actually, if you don't get to read a full chunk, you don't have the data for both audio channels, so discarding is the only sane thing to do. Unintentionally did the right thing lol... :)

Oops... Seems I am getting sidetracked again... Fun to have something that has "flawlessly" been working for weeks crash like this:

STAAudioCoordinator: could not fill entire buffer, will clear the rest of the buffer for now. Read 512.
Block Size: 3383413356
Last Sample: 7302926928557966667
objc[6886]: Hash table corrupted. This is probably a memory error somewhere. (table at 0x7fff72991490, buckets at 0x1009ea600 (4096 bytes), 256 buckets, 31 entries, 87 tombstones, data 0x84e54b0084ce8b 0x8512d10084fc0d 0x85405f00852997 0x856df400855729)
Hiding progress bar.
objc[6886]: Hash table corrupted. This is probably a memory error somewhere. (table at 0x7fff72990e10, buckets at 0x100a03200 (4096 bytes), 256 buckets, 26 entries, 82 tombstones, data 0xa92bea00a9124f 0xa95f2700a94588 0xa9926c00a978c8 0xa9c5b700a9ac11)

Pretty obvious what happened here, but why? Time to put some sanity checking into the DSF-player at least, but those values are just insane...

Edit:

Found one error that contributed, but I don't think this is the whole story:

Before:

    if ([iStream read:bufferLeft maxLength:blockSize] == 0) {mIsEndOfSong = YES; return NO;}
    if ([iStream read:bufferRight maxLength:blockSize] == 0) {mIsEndOfSong = YES; return NO;}

After:

    if ([iStream read:bufferLeft maxLength:blockSize] != blockSize) {mIsEndOfSong = YES; return NO;}
    if ([iStream read:bufferRight maxLength:blockSize] != blockSize) {mIsEndOfSong = YES; return NO;}

Sometimes I just shake my head of the silly errors I make...

Edit 2:

Seems I located the source for the error. I have postponed refactoring the bit file reader for too long. Time to solidify and complete all the functionality I have planned for this class. Seems it get hiccups at end of file situations sometimes. Also the weird thing that it tends to sometimes cut the end of songs, not only on FLAC but also on DSF indicates that it is the bit file reader that is buggy and needs some more work.