-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lots of code cleanup -- removing unused variables #19
base: master
Are you sure you want to change the base?
Conversation
Attempt to code led level meters appropriately in audio_osx.c
Sorry, I saw the commit but not the pull request, so I thought you were still working on it.
|
Apart from that it compiles fine (for my reference, I need to add
|
I'll see if I can find time tonight to check if the debug output produces anything useful. |
I've been looking at it some, and nothing pops out at me yet.
Does it play audio at all?
On Tuesday, January 26, 2021, 11:43:29 AM PST, AlisterH <[email protected]> wrote:
I'll see if I can find time tonight to check if the debug output produces anything useful.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
…it's estimate of the current frame played is correct Added audio_device_processed_frames() function to audio_(alsa|oss|pa|osx).c -- that is really what audio_util needs to have
diff --git a/audio_osx.c b/audio_osx.c int process_audio(gfloat *pL, gfloat *pR) |
entering start_gwc_playback with audio_playback=0 |
On a real mac if I try looping it does play, once. |
Actually, sorry, when I build on the real mac this behaviour now seems to go back well before your changes. |
Take what I put up there now for OSX and give it a go when you get a chance. I won't touch it until you report back. No rush.
On Wednesday, January 27, 2021, 12:01:19 PM PST, AlisterH <[email protected]> wrote:
Actually, sorry, when I build on the real mac this behaviour now seems to go back well before your changes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
It builds with this change, but only fixes it on a virtual machine - behaviour is unchanged on a real Mac (which also has a much more recent OSX FWIW)
|
When you say behaviour is unchanged, do you mean it prints one of the DEBUG messages from:
printf("DEBUG:============ OSX says current Frame # is %ld\n", playback_read_frame_position) ;
And then just shuts down playback because it has calculated the playback frame is greater than the last frame?
On Friday, January 29, 2021, 10:34:26 AM PST, AlisterH <[email protected]> wrote:
It builds with this change, but only fixes it on a virtual machine - behaviour is unchanged on a real Mac (which also has a much more recent OSX FWIW)
a/audio_osx.c
+++ b/audio_osx.c
@@ -197,7 +197,7 @@ Float64 coreaudio_running_clock_time(void)
OSStatus err;
UInt32 num_processes;
UInt32 count;
- extern int audio_playback ;
+ //extern int audio_playback ;
count = sizeof(UInt32);
if ((err = AudioDeviceGetProperty (audio_data.device, 0, false, kAudioDevicePropertyDeviceIsRunning,
@@ -313,6 +313,7 @@ int audio_device_write(unsigned char *buffer, int buffersize){return 0;} // Not
long audio_device_processed_frames(void)
{
+ extern int audio_playback ;
Float64 running_frame_number = coreaudio_running_clock_time() ;
if(running_frame_number < 0.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Yes, output looks the same to me:
|
Actually, play has worked for me twice (out of maybe a hundred attempts on the real mac), and the cursor tracked properly as it played, and the ledbars worked.
|
ok thanks. Frustrating, but learning some things. coreaudio documentation very poor.
I have another idea how to approach it.
On Friday, January 29, 2021, 10:54:56 AM PST, AlisterH <[email protected]> wrote:
Yes, output looks the same to me:
./gwc
Current stack limit: 8388608 bytes
libsndfile Version: libsndfile-1.0.28 1 0 28
entering start_gwc_playback with audio_playback=0
Could not get the current time. The error number is: 1937010544
Initializing led_levels data, totblocks=11
START GWC PLAYBACK audio cursor position=133994
start_gwc_playback starting playback timers
leaving start_gwc_playback with audio_playback=1
DEBUG:============ OSX says current Frame # is 1401273512
update_cursor is ending audio_playback CP:1401362636, last:178863 diff:-1401183773
prefs.rate:44100
DEBUG:============ OSX says current Frame # is 1401273515
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
oh -- sounds like there is an unpredicable lag in the coreaudio initialization functions. wonder if a little microsleep for a millesecond might be in order.
On Friday, January 29, 2021, 11:03:24 AM PST, AlisterH <[email protected]> wrote:
Actually, play has worked for me twice (out of maybe a hundred attempts), and the cursor tracked properly as it played, and the ledbars worked.
Interestingly, when looping (which actually only plays once) the cursor doesn't track and the ledbars don't work, with lots of messages like this. But in the virtual machine the cursor does track and the ledbars do work when looping.
Uh-oh, current_level_block:80, max:10
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Sorry, I've been away for the week, without access to the test machine.
Reducing the usleep to 4000 it works most but not all of the time. |
Correction - that change makes playback start correctly, but there are then two issues:
|
Attempt to code led level meters appropriately in audio_osx.c
Alister -- I anticipate at a minimum there will be leftover unused variables in audio_osx.c Likely some typos as well.
While all I did, theoretically is remove unused variables, and clean up warnings in all the code, this is really in need of serious testing to make sure I didn't create new bugs. It compiles cleanly (save 1 warning about ignoring the result of a system call in gwc.c) I made a new branch so we can test it before merging back into master.