Akai Force Forum: Everything relating to the Akai Force, the new 64 pad, clip-based standalone sampler/groovebox from Akai. While not an MPC, it shares many similar software features to the MPC X/MPC Live including the same underlying code-base.
By zenguru Thu Dec 16, 2021 5:18 pm
EnochLight wrote:Congrats on getting your issue fixed! So it looks like it wasn't an Akai issue/bug at all, it was a poorly performing SSD? Did you compare the read/write performance specs of your old SSD compared to your new one (like is there that much of a difference)? Was your old SSD "really old"?


I hate to say this but apparently the problem is still there with the new SSD, Samsung 870 EVO 250GB. It might work a little bit better though, but I still get the glitch sometimes.

Also today I experienced something weird, the clips started to play out of sync when I launched a scene! So yes, I think there is a bug or two in there.

The old SSD was maybe 5 years old, so kind of old, but according to the speed specs should still be fast. It seems the speed of the SSD doesn't play a big part here. The problem is somewhere else.
User avatar
By EnochLight Fri Dec 17, 2021 9:44 pm
zenguru wrote:
EnochLight wrote:Congrats on getting your issue fixed! So it looks like it wasn't an Akai issue/bug at all, it was a poorly performing SSD? Did you compare the read/write performance specs of your old SSD compared to your new one (like is there that much of a difference)? Was your old SSD "really old"?


I hate to say this but apparently the problem is still there with the new SSD, Samsung 870 EVO 250GB. It might work a little bit better though, but I still get the glitch sometimes.

Also today I experienced something weird, the clips started to play out of sync when I launched a scene! So yes, I think there is a bug or two in there.

The old SSD was maybe 5 years old, so kind of old, but according to the speed specs should still be fast. It seems the speed of the SSD doesn't play a big part here. The problem is somewhere else.


Have you tried the 3.1.2 firmware that just dropped a couple of days ago?
By nori Sat Dec 18, 2021 1:56 pm
zenguru wrote:Sorry, I can't share the project, but it's 8 audio tracks, 76 audio files spread over 30 scenes, 4.3 GB in total.


Are you able to convert the drum parts to drum groups and trigger those as midi? Or just load say 1gb of the set into ram and stream the rest?

Might ease up the strain on disk streaming.

As I understand the ssd is basically run off a usb port and not a sata port so it does not get full ssd read/write speeds.
User avatar
By EnochLight Sat Dec 18, 2021 5:02 pm
nori wrote:
zenguru wrote:Sorry, I can't share the project, but it's 8 audio tracks, 76 audio files spread over 30 scenes, 4.3 GB in total.


Are you able to convert the drum parts to drum groups and trigger those as midi? Or just load say 1gb of the set into ram and stream the rest?

Might ease up the strain on disk streaming.

As I understand the ssd is basically run off a usb port and not a sata port so it does not get full ssd read/write speeds.


Thing is, he's only running 8 audio tracks. Force can easily disk-stream that many, even on the crappiest performing SSD on the market. You're right about Force (as well as MPC) using a USB bus for the SATA port, but USB 2.0 has been doing stereo multitrack for almost 2 decades quite easily. That's definitely not his problem. As I said, I can disk-stream well over 20+ stereo audio tracks from my Force without glitching or pop/click at all...
By zenguru Sun Dec 19, 2021 11:28 am
EnochLight wrote:Have you tried the 3.1.2 firmware that just dropped a couple of days ago?


Yes, but there’s no difference.
By zenguru Sun Dec 19, 2021 11:42 am
nori wrote:Are you able to convert the drum parts to drum groups and trigger those as midi? Or just load say 1gb of the set into ram and stream the rest?

Might ease up the strain on disk streaming.

As I understand the ssd is basically run off a usb port and not a sata port so it does not get full ssd read/write speeds.


I will convert some parts to drum groups later, but I had a gig on friday and didn’t have the time to do that before the gig. I’m quite sure this would ”fix” the issue.

The gig went great though, but I had to “preload” every clip before launching them.

I also have tried to have some parts in RAM, but I still had the same issues.
By zenguru Sun Dec 19, 2021 2:38 pm
EnochLight wrote:Thing is, he's only running 8 audio tracks. Force can easily disk-stream that many, even on the crappiest performing SSD on the market. You're right about Force (as well as MPC) using a USB bus for the SATA port, but USB 2.0 has been doing stereo multitrack for almost 2 decades quite easily. That's definitely not his problem. As I said, I can disk-stream well over 20+ stereo audio tracks from my Force without glitching or pop/click at all...


I need to make some tests, but I think the issue is somehow related to the amount of simultaneously launched clips and the lenght of those clips. So it actually could be a bandwidth issue, even though Force is indeed able to stream 8 tracks at once. It’s just that visually rendering the waveforms of the clips actually require more bandwidth than streaming them. There’s no need to render them however, unless specifically going to the clip mode, and that’s where the bug is, I believe. The clips play fine when I open the clip view for each clip that are going to be played next. This way the waveforms are already rendered when I launch the scene and there’s no other things besides the audio to take up the bandwidth.

I’ll report my findings later.
User avatar
By EnochLight Sun Dec 19, 2021 5:26 pm
Cool, let us know how it goes!
By nori Tue Dec 21, 2021 8:57 pm
EnochLight wrote:Thing is, he's only running 8 audio tracks. Force can easily disk-stream that many, even on the crappiest performing SSD on the market. You're right about Force (as well as MPC) using a USB bus for the SATA port, but USB 2.0 has been doing stereo multitrack for almost 2 decades quite easily. That's definitely not his problem. As I said, I can disk-stream well over 20+ stereo audio tracks from my Force without glitching or pop/click at all...


Are your 20+ tracks (project) the size as OP? Like 4gb ish? Be interesting to see if file size/length or even sample rate has any impact.

I was thinking there must be some buffering going on to stream such large audio files so reducing that might help fix the issue.

Its true that usb 2 has enough theoretical bandwidth but if you copy huge multigig files over usb, you will see that the speed drops when the buffer is full. I also assume that there is some overhead for converting between sata and usb transfer protocols.

I have a couple usb 2 to sata adapters that i use quite often to backup/clone my disks to ssd and I definitely see big drops in I/O after the buffer is full. Like 25% of original performance. This is on Intel, Samsung, Corsair and WD ssd's. So I am guessing this might be contributing to the issues :hmmm:
By nori Tue Dec 21, 2021 9:18 pm
Oops, didnt see OP's post about the waveforms. I guess its a cpu thing too.
User avatar
By EnochLight Wed Dec 22, 2021 9:30 pm
nori wrote:
EnochLight wrote:Thing is, he's only running 8 audio tracks. Force can easily disk-stream that many, even on the crappiest performing SSD on the market. You're right about Force (as well as MPC) using a USB bus for the SATA port, but USB 2.0 has been doing stereo multitrack for almost 2 decades quite easily. That's definitely not his problem. As I said, I can disk-stream well over 20+ stereo audio tracks from my Force without glitching or pop/click at all...


Are your 20+ tracks (project) the size as OP? Like 4gb ish? Be interesting to see if file size/length or even sample rate has any impact.


Had some time off today and was bored, so I spent the afternoon running some tests.

THE TEST

This was all done on the public release of Force Firmware 3.1.2. Just fired up the sessions I made to test this (I've tried it with two different projects). One project - a single song - is 26 stereo stems (24 bit, 44.1 Khz) that total about 2.13 GB before import (it's roughly a 6+ minute song total, so each of the 26 stems are about 6+ minutes in length). The larger is a test session that consists of 23 stereo 24-bit 44.1 Khz audio stems, each one is roughly 1 hour in length (soooo 23 hours of audio total), for a disk-streaming crushing total project size of... 23.6 GB.

After setup (see below), my RAM hovered around 2%, THAT'S TWO PERCENT!!! :smoker: :worthy: and my CPU was around 25% during playback (for the session with 23 stereo stems disk streaming - I forgot to check what the 26 stem Project hovered at but can't imagine it was much different). IMHO, this leaves plenty of headroom for adding insert effects and other tracks with more Keygroups, Drum Programs, Plugins, MIDI control, etc. Anyway, playback for both Projects was flawless - no pop/click, and everything played just fine. One thing I did notice with the 26 stem Project is that some audio tracks would "disappear" for no particular reason, even though the waveform/Clip appeared to be loaded. So, that's a thing.

SETUP:

So, to be clear - this is really just a "proof of concept" test. I loaded all files from an attached USB3 stick, setup everything to stream from disk, then saved the Project onto my Force's internal 1 TB SSD, and opened the Project from my internal 1 TB SSD after everything was saved to stream from disk to do playback. Warp was manually turned off for all stems.

There's some "preparation" one must do when you plan to stream more than 8 audio files from disk. Once you fill up all 8 audio tracks on Force, you have to resort to loading remaining audio files into a Drum Program. The problem is, by default Drum Program only allows you to load into RAM, so it will constantly throw up "Low Memory!" warnings when you load each audio file to a pad. After you load the audio file, you have to go into your Project settings, long press the recently loaded sample, and select "Stream From Disk" as the option. Then you have to wait until Force flushes the sample from its RAM and sets it up to stream from disk, which can take 10-15 seconds. Every. Time.

It's sort of a pain in the ass, and I wish Akai would let us change Drum Program to automatically stream from disk as an option, but they're really not encouraging people to use the Drum Program streaming as an option/work-around IMHO as you can quickly saturate your disk bandwidth and bring Force to its knees if you attempt to play a streaming Drum Program like a drum kit.

FUN FACT:

Doing the initial save of those Projects once I imported the audio (basically transferring the audio from my USB3 stick to Force's internal 1 TB SSD that I installed) takes a long, long, LOOOOONG ass time. We're talking almost 2 hours! Lol :lol: So really not sure how "practical" something like this is in a production environment if you need to change/edit the audio, as it will resave the entire Project even if you only edit 1 audio file**. But... that said, once setup and initially saved, loading said project from my 1 TB SSD is almost instantaneous.

** could be wrong about this - need to test when I get the time.
By nori Sat Dec 25, 2021 11:41 pm
:worthy:
Wow, that is actually really impressive!

Just curious but what brand/model is your 1tb drive?
User avatar
By EnochLight Tue Dec 28, 2021 6:35 am
nori wrote::worthy:
Wow, that is actually really impressive!

Just curious but what brand/model is your 1tb drive?


Samsung SSD 870 EVO 1TB, though any generation after that is perfectly fine IMHO...
By zenguru Sun Jan 23, 2022 8:49 pm
I have now performed two live sets using the same project. The first time I didn't notice any issues while playing, but the set was recorded and I can hear it happening at least once. The second time I noticed it while I was playing. I also experienced the issue many times while practicing the set.

I haven't touched my Force for a while, but now I had some spare time for testing. Strangely I couldn't reproduce the issue!

There was a difference in the test setup though. In the live sets I had a USB midi controller and a CV controlled synth hooked up. The synth was fed into an external reverb and back to Force as stereo (inputs 1 & 2). The controller is a Novation Launch Control XL mk2. Almost all knobs are mapped to different parameters.

It seems the Force is able to play the clips just fine without the external stuff hooked up. I need to test this more.
By misterflibble Sat Jan 29, 2022 2:26 pm
Thanks for sharing the detailed info on the issue, test run, and outcome.

I’ve noticed that the Force struggles a bit with rendering waveforms on large audio files. I will occasionally record stuff off YouTube into my Force, and I pulled in an hour-long DJ set into it the other day. I started recording it into the sampler before I realized how long it was, and really should have laid it down on to an audio track, but I just let it run. The resulting audio file ended up being about 1GB if memory serves, for just under 60 minutes of recording (the sampler caps you to 60:00 on the 3.1.2 firmware).

I also noticed that save times take a while, certainly longer than I’d expect for a sequential write to an SSD. I want to say it took between one to two minutes to save the file. Taking the word of the folks on here that there’s a USB2.0 interface between the drive and the mainboard, USB 2.0 clock speed is 480 megabits per second. That's 60 megabytes per second, best case. Given the protocol overhead and the fact that USB 2.0 is half-duplex, the maximum data rate will be 30-40 megabytes per second. For a 1GB file that should be about thirty seconds. Obviously, the Force takes longer to perform these writes for whatever reason. That could be an issue with either the software or hardware. I can’t remember the exact model number of the SSD I installed but I believe it was a 1TB or 2TB Samsung 860 EVO. For a sequential write that drive will definitely handle 30-40MB/s with ease. If I remember and get time later on I’ll try writing that sample to disk again and will time it.

As for the waveform rendering, we should be looking at about the same time for rendering at a minimum, under the auspice that the Force has to read the file off disk in its entirety to do the rendering. There would also be the added CPU overhead and any constraints for bandwidth to RAM for any file system operations that may have to go through RAM. It’s impossible to say how the I/O works in the software without the source code, since Linux gives you a variety of ways to open a file.

Based on OP’s 23.6GB project taking almost two hours to save, that’s only about 4MB/s on average if we assume a save time of 1h 45m. That’s around 10-15% of the USB2.0 protocol bandwidth. So my guess is there’s something inefficient happening in the software, or the USB2.0 controller in use can’t reach the maximum speed of the protocol for whatever reason. The comment earlier about I/O slowing to a crawl once the buffer on the USB controller is filled could explain it. I don’t know what mechanisms USB has for backpressure when a buffer is filling up, but buffers are supposed to improve thoughput, not slow it down. If the Force OS is firehosing the controller and causing it to do extra work for some reason then this could be introducing inefficiency. And if so, modifying the Force OS to do a rate-limited write, matched to the buffer size and throughput of the USB controller might help. Another limit could be memory bandwidth from the mainboard. But that’s all speculation.

Finally, if the issue is exacerbated by external USB devices being attached, that could be due to additional traffic traversing the USB controller in the Force. Even if these operations aren’t bandwidth-intensive, depending on what the external devices are trying to do, there may be blocking operations of some kind taking place that temporarily interrupt I/O to the internal drive either by dominating the USB controller’s time for some reason or forcing it to make some kind of serial operation at the expense of the drive I/O.

There’s a good discussion on USB2.0 limitations and caveats here.

https://superuser.com/questions/317217/ ... b2-0-drive

EDIT: I dug around for a bit for the Radxa Rock2 SoM data sheet to see if they had a block diagram that might show the interconnects between the components, but looking at the MPC tear down, Akai seems have a custom baseboard, which I guess makes sense. There are downloads on the Radxa wiki for the SoC. This page at least confirms that the I/O path to the SATA drive traverses a USB2.0 to SATA bridge. With this being an SoC with the memory on the die, and it being DDR3 I’d be shocked if memory bandwidth was a constraint. It would be ludicrous (but not impossible) for Akai’s board to limit I/O from the SoC in some manner - when you’re working with a budget, anything can happen. So all that said, my guess is that the crappy throughput to the drives is probably software-related or limited by the throughput of whatever chipset is doing the USB to SATA conversion.

https://www.cnx-software.com/2014/11/05 ... fications/