Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - AquaBytez

Pages: [1]
1
Audio / Re: How exactly does SoundFileReaderFlac work?
« on: March 18, 2019, 09:35:40 pm »
Everything matches, sampling rate, bit rate, # of channels. The input file is a 44100, 16bit, 2 channel FLAC file. The playback format is the exact same. I can confirm that the playback code is fine (it works with decoded WAV data), the problem seems to be with the FlacReader, but I'm not too familiar with FLAC, even after going through the format docs more than 3 times already.

2
Audio / How exactly does SoundFileReaderFlac work?
« on: March 14, 2019, 06:28:41 pm »
Since I based this code off the SFML codebase, I thought that this was the right place to ask, so here it goes:

Long story short: I wanted to learn about the inner workings of the audio module, so I decided to try making a subset of it (only OGG and FLAC, decided to start with FLAC), completely independent from SFML. It is Windows only at the moment,  but that is not a concern, as I don't plan to use this on production code, just as my own personal learning tool.

The problem is that, while audio reading/decoding and playback work, the samples seem to be being read very slowly (alternatively, the playback is stremely slow, feels like the music is at least 2x slower than normal). I'm using WASAPI for playback on Windows. Here's the code:

FlacReader.h
(click to show/hide)

FlacReader.cpp
(click to show/hide)

And the code I use for playback (excuse the mess, I already mentioned that I don't intend to use this code anywhere besides a learning environment).

(click to show/hide)


I think the the problem is on this section of the code:
(click to show/hide)
However, I'm unable to determine exactly what's wrong with it. The original code uses 16bit integers, which are shorts on my system. I changed all sf::Int16 in the original code to int32_t, and modified the decoding code accordingly. As far as I'm aware anyways. The only other major changes are the use of shared and unique ptrs, and the replacement of sf::InputStream for a regular ifstream. On the WASAPI side, the hacked together mix format perfectly matches the metadata of the test file I'm using. So that's is ruled out as a problem.

Pages: [1]
anything