AlisterH
Lots of code cleanup -- removing unused variables
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.
Sorry, I saw the commit but not the pull request, so I thought you were still working on it.
diff --git a/audio_osx.c b/audio_osx.c
index 7d9d17a..066d23e 100644
--- a/audio_osx.c
+++ b/audio_osx.c
@@ -127,8 +127,8 @@ macosx_audio_out_callback (AudioDeviceID device, const AudioTimeStamp* current_t
extern int audio_is_looping ;
extern gint totblocks_in_led_levels ;
extern int buffered_looped_count ;
- extern gfoat *led_levels_l ;
- extern gfoat *led_levels_r ;
+ extern gfloat *led_levels_l ;
+ extern gfloat *led_levels_r ;
extern gint LED_LEVEL_FRAME_SIZE ;
if(audio_is_looping == FALSE || buffered_looped_count == 0) {
diff --git a/audio_util.c b/audio_util.c
index 7921336..0d1927e 100644
--- a/audio_util.c
+++ b/audio_util.c
@@ -352,8 +352,8 @@ gint LED_LEVEL_FRAME_SIZE = 4410 ; // number of frames examined for max values
extern int audio_is_looping ;
extern gint totblocks_in_led_levels ;
extern int buffered_looped_count ;
- extern gfoat *led_levels_l ;
- extern gfoat *led_levels_r ;
+ extern gfloat *led_levels_l ;
+ extern gfloat *led_levels_r ;
extern gint LED_LEVEL_FRAME_SIZE ;
void get_led_levels(gfloat *pL, gfloat *pR, gfloat *pLold, gfloat *pRold, long frame_number)
Apart from that it compiles fine (for my reference, I need to add CFLAGS="-fnested-functions" when running configure).
Playing still produces this:
Initializing led_levels data, totblocks=106
START GWC PLAYBACK audio cursor position=0
start_gwc_playback starting playback timers
Process Audio for OS X is now broken, need to fix it for led_level_
leaving start_gwc_playback with audio_playback=1
Process Audio for OS X is now broken, need to fix it for led_level_
!!!!!!!!!!!! processed bytes < 0!
update_cursor is ending audio_playback CP:507959, last:507959 diff:0
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.
diff --git a/audio_osx.c b/audio_osx.c index 0c6f35f..6fb34c7 100644 --- a/audio_osx.c +++ b/audio_osx.c @@ -164,6 +164,7 @@ macosx_audio_out_callback (AudioDeviceID device, const AudioTimeStamp* current_t }
int process_audio(gfloat *pL, gfloat *pR) +{ if(audio_state == AUDIO_IS_IDLE) { d_print("process_audio says AUDIO_IS_IDLE is going on.\n") ;
entering start_gwc_playback with audio_playback=0 Free-ing led_levels data Initializing led_levels data, totblocks=48 START GWC PLAYBACK audio cursor position=65153 start_gwc_playback starting playback timers leaving start_gwc_playback with audio_playback=1 DEBUG:============ OSX says current Frame # is 1230433108 update_cursor is ending audio_playback CP:1230289278, last:274135 diff:-1230015143 prefs.rate:44100 DEBUG:============ OSX says current Frame # is 1230433110
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)
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.)
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:
./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
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. 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
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. Yes, I'm not sure if I've put it where you were thinking, but this seems to make it work reliably:
diff --git a/audio_osx.c b/audio_osx.c
index 99b1b2a..7bf62f0 100644
--- a/audio_osx.c
+++ b/audio_osx.c
@@ -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.)
diff --git a/gwc.c b/gwc.c
index 4b2d51f..72538ce 100644
--- a/gwc.c
+++ b/gwc.c
@@ -1247,7 +1247,7 @@ void start_gwc_playback(GtkWidget * widget, gpointer data)
audio_playback = TRUE;
audio_debug_print("START GWC PLAYBACK audio cursor position=%ld\n", audio_view.cursor_position) ;
-
+ usleep(5000) ;
if (audio_playback == TRUE) {
gfloat l, r;
audio_debug_print("start_gwc_playback starting playback timers\n") ;
Reducing the usleep to 4000 it works most but not all of the time. Reducing to 3000 it only works occasionally. Whether more than 5000 might be needed on a different machine is another question...
Correction - that change makes playback start correctly, but there are then two issues:
- playback does not usually stop at the end of the view/selection - it keeps going to the end of the file (at least with the fairly short recording I'm testing with), with those
Uh-oh, current_level_block:50, max:33messages. - if playback is stopped manually, starting playback again works reliably, but if playback stops because it got to the end of the file (or the end of the view/selection on the occasions that it stops there) then trying to start playback again often fails, and it often won't work again without restarting the program.