Playback too slow for hard drives

[vloddot]

Playing a flac file on a hard drive is too slow and cuts audio out a lot. ( every few seconds) I've also noticed that playing the same sound file twice seems to cache it somehow and runs fine but practically, that almost never happens.

Since I know a bit of C programming, I tried to see what was wrong, I looked at the miniaudio documentation and found that using the low-level API (simple playback example) is what causes this issue. Using the high-level API, using an ma_resource_manager or moving the flac file to an SSD makes it work perfectly. I'm sure using the low-level API is required for performance but I don't know the internals of why this issue happens exactly.

I have not tested a different file format yet so it may be an issue with flac files and hard drives specifically. (or something with my device)

Result of ffprobe on one of the files as described in CONTRIBUTING.md:

{
    "streams": [
        {
            "index": 0,
            "codec_name": "flac",
            "codec_long_name": "FLAC (Free Lossless Audio Codec)",
            "codec_type": "audio",
            "codec_tag_string": "[0][0][0][0]",
            "codec_tag": "0x0000",
            "sample_fmt": "s32",
            "sample_rate": "48000",
            "channels": 2,
            "channel_layout": "stereo",
            "bits_per_sample": 0,
            "initial_padding": 0,
            "r_frame_rate": "0/0",
            "avg_frame_rate": "0/0",
            "time_base": "1/48000",
            "start_pts": 0,
            "start_time": "0.000000",
            "duration_ts": 11346756,
            "duration": "236.390750",
            "bits_per_raw_sample": "24",
            "extradata_size": 34,
            "disposition": {
                "default": 0,
                "dub": 0,
                "original": 0,
                "comment": 0,
                "lyrics": 0,
                "karaoke": 0,
                "forced": 0,
                "hearing_impaired": 0,
                "visual_impaired": 0,
                "clean_effects": 0,
                "attached_pic": 0,
                "timed_thumbnails": 0,
                "non_diegetic": 0,
                "captions": 0,
                "descriptions": 0,
                "metadata": 0,
                "dependent": 0,
                "still_image": 0
            }
        }
    ]
}

More info:

• OS: Arch Linux 6.9.2-arch-1.1 x86_64
• Installed via AUR package
• CPU: Intel(R) Core(TM) i7-5500U (4) @ 3.00 GHz

[ravachol]

Is it a massive change to use the ma_resource_manager? I haven't looked into it and a bit busy at the moment.

[vloddot]

I'm only looking at the simple playback example from the miniaudio documentation since I'm not too knowledgeable about the codebase but here are the differences:

• Instead of ma_decoder, ma_resource_manager_data_source is used.
• ma_resource_manager is initialized to allow the initializing of ma_resource_manager_data_source.

You can see the Simple Playback example here and the Resource Manager example here.

[vloddot]

Digging through the code, I see that something called ma_data_source_base is used instead of ma_decoder.

Edit: A custom data source apparently.

[ravachol]

Ok, thank you so much for this!

[vloddot]

You're welcome! Sorry for bothering you while you're busy.

[vloddot]

I recently reformatted my drive to ext4 instead of btrfs and apparently the cut outs were due to the slow read/write operations by btrfs. Nontheless, this is still an actual issue.

[ravachol]

Ok. I just committed the latest to the develop branch, in case you want to play around with it. The internal structure is a bit messy though, I'm more used to OOP than this stuff. But it's a lot of fun.

[vloddot]

Wrong issue.. #132

[ravachol]

hm?

[vloddot]

Your changes were about implementing searching so I assumed you meant to comment on the other issue.

[ravachol]

No, I meant this one. Next release is going to have search too, yeah.

[vloddot]

I can't seem to find changes relating to using ma_resource_manager but I'll still try it.

[ravachol]

Cool!

[vloddot]

Sorry for taking a while to test, I was busy and had to reformat my drive to btrfs to test. Same issue still occurs, I really don't see any difference in the source code that changes how audio is processed.

[ravachol]

Oh I didn't make any changes to it. I just thought maybe you wanted to play around with the code, so I pushed the latest stuff I had. You don't have to of course, but if you do you can do it on the latest code. No experienced c programmer except you has showed up yet.

[vloddot]

Alright then, I'll try to in my free time. Sorry for misunderstanding.

[vloddot]

Sorry, I've been busy the past few weeks. I'll see if I can do anything about it. I'll ask for help if I need it.

[ravachol]

I looked at it a little and it seems like a hard thing to change, one reason is because I am linking those decoders together to have gapless playback, and there is quite a bit of code related to that and usage of ma_decoder. I don't know if it's possible to do gapless playback with a ma_resource_manager.

[vloddot]

I don't really think it's worth it to use a resource manager then. A custom implementation for drives with low read speeds would help but I wouldn't think the incredibly specific use-case I had would be worth that effort or help many people. btrfs isn't really meant to be used on hard drives anyway. I'm in no place to speak of course but I think this should be marked as unplanned. You're free to do as you want but the problem has been solved for me in the end.

[ravachol]

Ok, cool. How did you solve it for yourself? Just moved the music to a ssd?

[vloddot]

I recently reformatted my drive to ext4 instead of btrfs and apparently the cut outs were due to the slow read/write operations by btrfs. Nontheless, this is still an actual issue.

SSD or reformatted to a faster filesystem.

[ravachol]

Ok, thanks for reporting this issue and helping out. Appreciate it.