aarch64 CI support

[mathaou]

Just wondering if anyone's tried compiling for aarch64, or if that would require extra work from the maintainers

[Be-ing]

I have and it works fine.

[wmedrano]

I renamed to issue to aarch64 support so that we can provide more than anecdotal evidence that aarch64 works.

[worikgh]

I am having problems running (not compiling) on aarch64

Early days, but using jackd -d dummy as a server and passing a sine wave through jack I am getting a lot of errors in the console running the client

This is using the exact same code as is working on x86_64

This is an unsatisfactory report, I know. I am working on creating a minimal test case.

[worikgh]

More information:

Running tests on Debian 13.2 on aarch64 and x86_64
The aarch64 is a Raspberry Pi 5
Using jackd -d dummy server
On commit 49d9ad1

aarch64

cargo test
warning: function pointer comparisons do not produce meaningful results since their addresses are not guaranteed to be unique       20:19:20 [12/1708]
  --> src/logging.rs:27:9                                                                                                                             
   |
15 | #[derive(Copy, Clone, Debug, PartialEq)]
   |                              --------- in this derive macro expansion
...                                                                        
27 |         info: unsafe extern "C" fn(*const ::libc::c_char),                                                                                       
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |            
   = note: the address of the same function can vary between different codegen units
   = note: furthermore, different functions could have the same address after being merged together
   = note: for more information visit <https://doc.rust-lang.org/nightly/core/ptr/fn.fn_addr_eq.html>
   = note: `#[warn(unpredictable_function_pointer_comparisons)]` on by default                                                                     
                                     
warning: function pointer comparisons do not produce meaningful results since their addresses are not guaranteed to be unique
  --> src/logging.rs:29:9
   |
15 | #[derive(Copy, Clone, Debug, PartialEq)]
   |                              --------- in this derive macro expansion
...
29 |         error: unsafe extern "C" fn(*const ::libc::c_char),
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: the address of the same function can vary between different codegen units
   = note: furthermore, different functions could have the same address after being merged together
   = note: for more information visit <https://doc.rust-lang.org/nightly/core/ptr/fn.fn_addr_eq.html>


warning: `jack` (lib) generated 2 warnings
warning: `jack` (lib test) generated 2 warnings (2 duplicates)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running unittests src/lib.rs (target/debug/deps/jack-6db3fde045916fff)

running 32 tests
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `/home/puppy/rust-jack/target/debug/deps/jack-6db3fde045916fff` (signal: 11, SIGSEGV: invalid memory reference)

That does not look good.

x86_64

There were two failures:

failures:                                                                  
                                                                           
---- properties::metadata::tests::client_callbacks stdout ----

thread 'properties::metadata::tests::client_callbacks' (286088) panicked at src/properties.rs:522:13:
assertion `left == right` failed
  left: Ok(Changed { subject: 8589934654, key: "blah" })
 right: Err(Timeout)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
JackMessageBuffer::SetInitCallback : callback could not be executed

---- tests::time::one_second_is_sample_rate_frames stdout ----

thread 'tests::time::one_second_is_sample_rate_frames' (286150) panicked at src/tests/time.rs:25:5:
assert_abs_diff_eq!((t1 - t0) as f64, client.sample_rate() as f64, epsilon = client.sample_rate() as f64 * 1e-3)

    left  = 0.0
    right = 48000.0




failures:
    properties::metadata::tests::client_callbacks
    tests::time::one_second_is_sample_rate_frames

[worikgh]

It turns out that I can run some tests on aarch64, so I ran them all individually

This is commit 73c4305 on aarch64 (Raspberry Pi 5, Debian 13.2)

Using the jackd -d dummy server

I restarted the server after each "failure" (None failed, they hang)

Test	Result
activating_client_notifies_buffer_size_before_beginning	passed
advancing_and_writing_shifts_vector	passed
advancing_transfers_space_from_writer_to_reader	passed
buffer_size_is_called_before_process	Hangs with xruns
can_property_remove_all	passed
can_remove	passed
can_set_and_get	pass
can_set_logger	pass
client_callbacks	Hangs
client_can_open	pass
client_uuid_are_unique	pass
frame_and_time_are_convertable	pass
maybe_client_can_set_buffer_size	pass
messages_in_midi_ports_are_forwarded	Hangs ^1
new_transport_is_not_valid	pass
nonexistant_uuid_to_client_name_returns_none	pass
one_frame_duration_is_inverse_of_sample_rate	pass
one_second_is_sample_rate_frames	pass
panic_in_buffer_size_handler_propagates_as_error_in_deactivate	Hangs
panic_in_process_handler_propagates_as_error_in_deactivate	Hangs
quitting_buffer_size_never_runs_process	Hangs ^2
quitting_stops_calling_process	Hangs
reading_and_writing_from_separate_threads_is_ok	pass
ringbuffer_new_creates_new_ringbuffer	pass
signals_in_audio_ports_are_forwarded	Hangs ^3
starting_transport_sets_state_to_started	pass
time_is_montonically_increasing	pass
uuid_can_map_to_client_name	pass
writing_and_advancing_produces_data_on_reader	pass
writing_to_writer_sends_to_reader	pass
written_bytes_can_be_peaked	pass

Notes - messages in console running jackd

1. "bad status"
2. "subgraph starting at timed out" and "pp: cannot clean up byte from graph wait fd - no data present"
3. "bad status (254) from client while handling a ports disconnected event" and "cannot send port connection notification to client (Resource temporarily unavailable)"

[worikgh]

More information:

On a Raspberry Pi 5 - aarch64

I am on Debian 13.2

I purged all Debian Jack packages.

I installed Jack from source (Github repo develop branch)

So now rust-jack is built against jack2 source

Running cargo test, nothing hangs and the process completes normally

Test	Result
can_property_remove_all	FAILED
can_remove	FAILED
can_set_and_get	FAILED
client_callbacks	FAILED
double_register - should panic	ok
client_can_open	ok
client_uuid_are_unique	ok
maybe_client_can_set_buffer_size	ok
nonexistant_uuid_to_client_name_returns_none	ok
time_is_montonically_increasing	ok
uuid_can_map_to_client_name	ok
can_set_logger	ok
activating_client_notifies_buffer_size_before_beginning	ok
buffer_size_is_called_before_process	ok
messages_in_midi_ports_are_forwarded	ok
panic_in_buffer_size_handler_propagates_as_error_in_deactivate	ok
panic_in_process_handler_propagates_as_error_in_deactivate	ok
quitting_buffer_size_never_runs_process	ok
quitting_stops_calling_process	ok
signals_in_audio_ports_are_forwarded	ok
advancing_and_writing_shifts_vector	ok
advancing_transfers_space_from_writer_to_reader	ok
reading_and_writing_from_separate_threads_is_ok	ok
ringbuffer_new_creates_new_ringbuffer	ok
writing_and_advancing_produces_data_on_reader	ok
writing_to_writer_sends_to_reader	ok
written_bytes_can_be_peaked	ok
frame_and_time_are_convertable	ok
one_frame_duration_is_inverse_of_sample_rate	ok
one_second_is_sample_rate_frames	FAILED
new_transport_is_not_valid	ok
starting_transport_sets_state_to_started	FAILED

[worikgh]

Building Jack with the Berkeley DB almost brings the aarch64 build, on Raspberry Pi 5 into line with x86_64, for me.
Only client_callbacks and starting_transport_sets_state_to_started are failing now.

The failing test client_callbacks is a simple problem with the test being too strict and there is a pull request for that