fix(whispering): fixed the issue with audio files on linux

[Github11200]

Summary

Fixes the issue where audio elements just showed some text saying error and weren't able to be played on Linux.

Changelog

• Audio elements can now be played on Linux in both the homepage and transcriptions page.

Type of Change

• feat: New feature
• fix: Bug fix
• docs: Documentation update
• refactor: Code refactoring (no functional changes)
• perf: Performance improvement
• test: Test additions or changes
• chore: Maintenance tasks
• style: Code style changes

Related Issue

Closes #1260

Changes Made

Inside an $effect block I first take the audio playback URL (something like asset://localhost/%2Fpath%2Fto%2Faudio%2Ffile) and change it to be /path/to/some/file. This is done with the following code:

const encodedPath = audioPlaybackUrl.slice('asset://localhost/'.length);
const filePath = decodeURIComponent(encodedPath);

With this file path, I then extract the raw blob data and create the blobUrl from that as shown below:

readFile(filePath).then((data) => {
    const fileBlob = new Blob([data]);
    const reader = new FileReader();
    reader.readAsDataURL(fileBlob);
    const url = URL.createObjectURL(fileBlob);
    blobUrl = url;
});

This blobUrl is then directly used inside the src property for the audio element. This same process is used inside the RenderAudioUrl.svelte file as well.

The reason I convert the file to a blob and put in as the src property is because directly using the asset://localhost gives a 403 forbidden error on Linux. I believe this is an issue with Webkit2GTK as outlined in the following issue on Tauri, tauri-apps/tauri#3725.

Testing

I ran bun test and tested it on Linux. However, I am not certain that this same code works on other platforms as well so it would be great if someone tested it out.

Desktop App Testing

• Tested on macOS
• Tested on Windows
• Tested on Linux
• Not applicable (web-only change)

General Testing

• Tested with multiple API providers (if applicable)
• Verified no API keys are exposed in logs or storage
• Checked for console errors
• Tested on different screen sizes (if UI change)

Checklist

• My code follows the project's coding standards (see CONTRIBUTING.md)
• I've used type instead of interface in TypeScript
• I've used absolute imports where applicable
• I've tested my changes thoroughly
• I've added/updated tests for my changes (if applicable)
• My changes don't break existing functionality
• I've updated documentation (if needed)

Additional Notes

The following snippet of code is duplicated across two files (apps/whispering/src/routes/(app)/+page.svelte and apps/whispering/src/routes/(app)/(config)/recordings/RenderAudioUrl.svelte):

const audioPlaybackUrl = $derived(audioPlaybackUrlQuery.data);
let blobUrl: string | undefined = $state(undefined);

$effect(() => {
	if (audioPlaybackUrl !== undefined) {
		console.log(audioPlaybackUrl);
		// Convert the path from asset://localhost/%2Fpath%2Fto%2Faudio%2Ffile to just be /some/path/to/file
		const encodedPath = audioPlaybackUrl.slice('asset://localhost/'.length);
		const filePath = decodeURIComponent(encodedPath);


		// Read the audio data in this file and then directly set that as the blob URL
		readFile(filePath).then((data) => {
			const fileBlob = new Blob([data]);
			const reader = new FileReader();
			reader.readAsDataURL(fileBlob);
			const url = URL.createObjectURL(fileBlob);
			blobUrl = url;
		});
	}
});

Obviously, this is not very ideal and I'm planning on extracting the logic inside of the $effect block elsewhere. However, I was wondering where this logic could be placed (is there a utility file that already exists that could hold the code?). If anyone has other suggestions on how it could be refactored then I would love to know!